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

[Peter Rosin]

Den 2010-09-03 18:05 skrev Charles Wilson:
> On 9/3/2010 7:59 AM, Peter Rosin wrote:
>> So, I'm now proposing this naming scheme instead:
>>
>> static lib:  foo.lib
>> shared lib:  foo-2.dll
>> import lib:  foo.dll.lib
>>
>> which is a lot more consistent with the MinGW naming, i.e.:
>>
>> static lib:  libfoo.a
>> shared lib:  libfoo-2.dll
>> import lib:  libfoo.dll.a
> 
> The only reason MinGW could do this, is that when we developed the
> cygmingw naming scheme, we simultaneously updated both gcc and ld to
> understand the new names, and imposed a search order:
> 
> 
>      For instance, when ld is called with the argument `-lxxx' it will
>      attempt to find, in the first directory of its search path,
> 
>           libxxx.dll.a
>           xxx.dll.a
>           libxxx.a
>           xxx.lib
>           cygxxx.dll (*)
>           libxxx.dll
>           xxx.dll
> 
>      before moving on to the next directory in the search path.
> 
>      (*) Actually, this is not `cygxxx.dll' but in fact is
>      `<prefix>xxx.dll', where `<prefix>' is set by the `ld' option
>      `--dll-search-prefix=<prefix>'.
> 
> This way, non-libtool unixish makefiles could always use -lfoo,
> regardless of whether they were linking to a static lib or dynamic lib.

Well, -lfoo didn't work for both static and shared libs in non-libtooled
use cases before this patch either, so status quo...

>  We can't similarly change the behavior of cl.exe -- unless you want to
> build THAT logic into the `compile' script (or is there a `linker' script)?

The thought did cross my mind. But not right now. (There is no 'linker'
script, so I would put it in the 'compile' script.)

>> On the negative side we have:
>>
>> * Inconsistent naming of import libs when comparing with other MSVC
>> libraries. They are typically named as the static lib, but so are
>> static libs, when that's what's shipped. Pick your poison.
> 
> Right. So anybody who uses libtool to build a core library, but then
> wants to build an application (which doesn't use libtool) that links
> against that DLL, will have to modify their makefile rules to say -lfoo.dll.

Or rename the import library files. But that's no fun either.

> Really, what this means is that non-libtool clients of libfoo will have
> to put detection machinery (in autoconf?) to determine whether libfoo.a
> or libfoo.dll.a exists; Makefile.in will have to use a subst variable so
> that either -lfoo or -lfoo.dll is specified in the Makefile...

But this was true before this patch too, but with s/-lfoo\.dll/-lfoo-2/
(which is worse since you have to keep track of the version as well).

> This would include most of libtool's own built-in tests, I would think.
> 
> Unless `compile'/`linker' becomes a lot smarter, and abstracts all that.
> (Actually, now that I think about this some more, modifying these
> scripts to implement search rules is probably a bad idea; they need to
> implement the SAME search rules as the underlying tool (cl.exe in this
> case), otherwise you'd get inconsistent results.  So, scratch that idea).

It's probably hard to get right, yes. But I'm not scratching it without
at least looking at it a bit more.

>> Besides, it's better to do this now, before the
>> first release of libtool with MSVC support, than after.
> 
> Well, that's true.  I have some misgivings about this plan, but you know
> best.

I don't really like it either. Not this way and not the way it was before
the patch, but there is no good way to do it when you have to feed the
exact library file name to MSVC. Hmmm, unless you put shared libs in one
set of directories and static libs in one set and play games with the
library search path. But that seems very hard too, and on top of that it
would be a MSVC-only solution and therefore a hard sell. I think adding a
matching library search to 'compile' is the best way forward (but again,
not now).

Doing the library search with this new naming is simpler too, since you
now know the exact names you are looking for when given -lfoo.

In short, all your issues were there before the patch too. With the
patch there is no file name clash for unversioned libraries and the
path forward is simpler.

Cheers,
Peter