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).