[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Adjust naming of MSVC import libraries.

From: Charles Wilson
Subject: Re: [PATCH] Adjust naming of MSVC import libraries.
Date: Sat, 04 Sep 2010 10:21:31 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

On 9/4/2010 4:52 AM, Peter Rosin wrote:
> If you are using -lfoo, then you *must* use 'compile' as well as cl
> does not know about the -l option. So, I was thinking that 'compile'
> instead of just transforming -lfoo into foo.lib would walk the library
> search path (in the same order as cl would) and replace -lfoo with
> either of foo.lib or foo.dll.lib depending on which was found first
> and possibly also modified by any -static or -shared flags (also not
> supported by cl, so -static and -shared would have to be completely
> handled by 'compile' and would only affect -lfoo handling, at least
> in my current thinking).

Remember that -static and -shared, the gcc options, are not antonyms:

     On systems that support dynamic linking, this prevents linking
     with the shared libraries.

     Produce a shared object which can then be linked with other
     objects to form an executable.

The former deals with what entities you will link to; the latter deals
with what type of output entity you will create.

For our current discussion, you would really only need to implement
-static handling; by default the "search" would prefer foo.dll.lib (but
would accept kernel32.lib).  With -static, the "search" would accept
only "foo.lib".

As with cygming, the link phase for -static would never try to verify
that "foo.lib" was actually a static library and not an import lib; it
would have to be a name-based search only (for the reasons you describe

-shared, obviously, would need to be translated into the appropriate
option to tell cl.exe to create a .dll (as opposed to an .exe).

> Note that -shared can't trigger 'compile' to always replace -lfoo with
> foo.dll.lib since a bunch of "system" libraries are shared but still
> named according as foo.lib (as Microsoft is obviously not following
> "my" naming convention). I think other "system" libraries are static
> and also named according to foo.lib, so it would do no good to "prefer"
> the import lib by naming it foo.lib and name the static lib something
> like foo.s.lib.

Right. That's the same conclusion we reached wrt .dll.a vs. .a

>> Agreed.
> And the testsuite runs have finished and results are the same. I still
> want to push this.

I have no objections anymore, but I can't approve it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]