Re^2: [Win32] The '-l' switch, and for which files the linker looks.

My confusion comes from phrases like "In a C environment" and "in a (MinGW-built) Perl environment".

An example:
Case 1 - what I (sloppily) meant by a "C environment":

gcc -o gmp.exe gmp.c -IC:/incs -LC:/libs -lgmp
[download]

Case 2 - what I (sloppily) meant by a "Perl environment"

perl Makefile.PL INC="-IC:/incs" LIBS="-LC:/libs -lgmp"
[download]

In the first case, I'm just building a test executable that needs the GMP library. It builds and runs fine.

In case 2, I'm trying to build Math::GMP - but that fails because "No library found for -lgmp". MakeMaker decrees that "-lgmp" means either "gmp.a" or "libgmp.a" - and in this particular instance, the import library that was built is named "libgmp.dll.a".

I had this half-baked idea that it would be nice if "-lgmp" worked the same in Case 2 as it did in Case 1 - and wondered if anyone had investigated the possibility. Hence my initial post in this thread. (MSVC compilers don't support the '-L' and '-l' conventions ... I probably should have omitted any consideration of those compilers.)

I've since been poking about a little, and I've just about decided that it's more trouble than it's worth. Far easier just to rename libgmp.dll.a to libgmp.a (and to do the same for other libraries, as necessary).

About the best that could be done to resolve the problem you are seeking to address, would be for the EU::MM to generate code in the makefile.pl it creates to cause it to go looking for each of the various suffixes when generating the makefile, and hardcode which ever it finds into the makefile

And wouldn't that be fun. I guess we could start by re-setting $Config{lib_ext} = ['.a', '.ddl.a', '.dll'] :-)
Though, as regards MinGW (but not MSVC), there should be no need to do any such hardcoding at all - unless it was decided to include '.lib' into the list of sought extensions, as I originally hinted. If '.lib' is not included then MakeMaker could just stick with the '-lfoo' stuff. There would be no need to convert to fully qualified file names, as is currently the case. And the libraries would be found at link time, irrespective of whether their names terminated with '.a', '.dll.a' or '.dll'.

Hmmm ... I wonder how much work that involves. I think that's the way it already works on nix systems, so it might not be as much work as one expects. That it would entail a major split with the way Makefiles are written for the MSVC compiler is less than enticing, but it's the thought of "what else gets broken" that's the major deterrent :-)

Cheers,
Rob

Comment on Re^2: [Win32] The '-l' switch, and for which files the linker looks. Select or Download Code

Replies are listed 'Best First'.
Re^3: [Win32] The '-l' switch, and for which files the linker looks. by BrowserUk (Patriarch) on Mar 08, 2008 at 09:14 UTC
MakeMaker decrees that "-lgmp" means either "gmp.a" or "libgmp.a" - and in this particular instance, the import library that was built is named "libgmp.dll.a". Are you saying that with your case 1 command line: `gcc -o gmp.exe gmp.c -IC:/incs -LC:/libs -lgmp`, the compiler or the linker does some kind of search and manages to resolve `-lgmp` to `libgmp.dll.a`? I guess that would mean that the suffix `.dll.a` has been adopted as a convention for naming import libraries. But also, if gcc manages to locate the file `libgmp.dll.a`, it would also mean that there was some convention that `-lxxx` would also search for `libxxx.a` and `libxxx.dll.a`? Or is this latter part just a MM convention? And wouldn't that be fun. I guess we could start by re-setting $Config{lib_ext} = '.a', '.ddl.a', '.dll' :-) Though, as regards MinGW (but not MSVC), there should be no need to do any such hardcoding at all - unless it was decided to include '.lib' into the list of sought extensions, as I originally hinted. If '.lib' is not included then MakeMaker could just stick with the '-lfoo' stuff. There would be no need to convert to fully qualified file names, as is currently the case. And the libraries would be found at link time, irrespective of whether their names terminated with '.a', '.dll.a' or '.dll'. That para still leaves me confused. (Sorry :) First off. link.exe will never do anything useful with a .dll file. Unless of course the file was actually a misnamed .lib (either an object library or an import library) or a misnamed .obj, in which case it would determine which type is was when it opened the file, and use it accordingly. But in anycase, naming either file type as .dll is just perverse. I guess what I'm saying here is that forget the .dll suffix when dealing with linking. Or does the gcc linker know how to resolve entrypoints directly against a .dll/.so? This is something that I remember questioning years ago when I first started building .dlls and trying to link them to .exes. If link.exe can generate an import library at the same time as it is building a .dll. And `implib` can generate an import library from a .dll. Why the hell can't we cut out the middle men and have link.exe resolve directly against a .dll? This was under OS/2, and the answer I got from the MS guys back then was less than informative--the great MS/IBM split occured not long after. But that's a different topic and not your concern. There is a lot of stuff about how MM generates makefiles for win32 that confuses the begebbers out of me. For example: You say that MSVC doesn't respect the `-L` convention, but it does have a direct equivalent `-libpath:dir` which MM uses (eg. `-libpath:"C:\Perl\lib\CORE"`) but then it goes on to use fully qualified pathnames for libs in that directory, eg. `C:\Perl\lib\CORE\perl58.lib`. Hmmm ... I wonder how much work that involves. I think that's the way it already works on nix systems, so it might not be as much work as one expects. That it would entail a major split with the way Makefiles are written for the MSVC compiler is less than enticing, but it's the thought of "what else gets broken" that's the major deterrent :-) Strikes me if gcc can resolve a `-lxxx` switch to all those different file names, having MM generate full names for them on win32 just makes extra unnecessary work. Better for MM to generate a nix style makefile and allow the nix compiler that has been adapted for win32 environments, to account for the differences. Then again, if the win32 adapted compiler can resolve all those different prefix and suffix combinations to `-lxxx`, it seems perverse that they don't also try for a .lib suffix. I guess my bottom line is that whenever I've wanted to build something badly enough, including Gtk on one occasion, I managed to hack the generated makefile manually, enough to get it to work. But every time I've looked to work out how to get the resultant hacked makefile, to be generated that way in the first place, I've ended up getting entirely lost and frustrated with the whole object-oriented, 'executable configuration files' that is EU::MM (and Module::Build). Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]
Re^4: [Win32] The '-l' switch, and for which files the linker looks. by syphilis (Archbishop) on Mar 09, 2008 at 07:40 UTC
Are you saying that with your case 1 command line: `gcc -o gmp.exe gmp.c -IC:/incs -LC:/libs -lgmp`, the compiler or the linker does some kind of search and manages to resolve -lgmp to libgmp.dll.a? Yep - that's effectively what happens. If it first finds a libgmp.a then it would use that ... and if libgmp.a, gmp.dll.a, libgmp.dll.a were all unlocatable it would look for (and then use) either libgmp.dll or gmp.dll. Or does the gcc linker know how to resolve entrypoints directly against a .dll/.so? Yes, it can do that. (Though assigning a '.so' extension would break all conventions.) It's probably a moot point, but I believe that (strictly speaking) only 2 file extensions are recognised - namely '.a' and '.dll'. The '.dll' in '.dll.a' is really part of the filename - certainly one can rename libfoo.dll.a to libfoo.a (and vice-versa) without introducing any problems. It looks like the convention is that '.dll.a' is an import lib (for a dynamic build) whereas '.a' is for a static library. But gcc doesn't need to know whether it's dealing with an "import lib" or a "static lib". Presumably the distinction is being made so that the programmer can instantly recognise whether it's a static or dynamic build. Otoh, if you want to link directly to libfoo.dll then gcc apparently does need to know that it's dealing with a dll. If you rename the dynamic library libfoo.dll to libfoo.a and link to it by specifying "-lfoo" on the command line, then linking will fail. Strikes me if gcc can resolve a -lxxx switch to all those different file names, having MM generate full names for them on win32 just makes extra unnecessary work. Agreed - and undoing that work is what I'm thinking about. I imagine that "extra unnecessary work" is simply there for the benefit of the Microsoft Compilers (which do need it), and that it was deemed easier to just lump MinGW and MSVC together where possible. That is, I think it quite likely that there are historical/evolutionary reasons that things are the way they are. But every time I've looked to work out how to get the resultant hacked makefile, to be generated that way in the first place, I've ended up getting entirely lost and frustrated with the whole object-oriented, 'executable configuration files' that is EU::MM (and Module::Build). It's heartening to hear that .... I had always assumed it was "just me" :-) Cheers, Rob	[reply] [d/l]
Re^5: [Win32] The '-l' switch, and for which files the linker looks. by BrowserUk (Patriarch) on Mar 09, 2008 at 08:12 UTC
Agreed - and undoing that work is what I'm thinking about.... it was deemed easier to just lump MinGW and MSVC together where possible. Hm. I don't envy you (or anyone) messing around in there. My thought was that since MinGW 'knows' how to deal with the peculiarities of Win32, it might be better to start will a cygwin style makefile (which generally seems to be pretty compatible with *nix equivalents), and tailor it for MinGW, rather than starting MSVC which is radically different. Ie. Most of the conflicts seem to be overzealous win32-ization of the makefile, conflicting with stuff that gcc already knows how to handle, and handles better. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]