in reply to Re^3: [Win32] The '-l' switch, and for which files the linker looks.
in thread [Win32] The '-l' switch, and for which files the linker looks.

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
  • Comment on Re^4: [Win32] The '-l' switch, and for which files the linker looks.
  • Download Code

Replies are listed 'Best First'.
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.
[reply]

In Section Seekers of Perl Wisdom