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

[Peter Rosin]

Den 2010-09-03 20:04 skrev Charles Wilson:
> On 9/3/2010 1:42 PM, Peter Rosin wrote:
>> Den 2010-09-03 18:05 skrev Charles Wilson:
>>> 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...
> 
> For MSVC.
> 
> Your assertion is not true for cygwin/gcc, mingw/gcc, or msys/gcc.

Obviously. The craziness discussed in this thread does not apply to Windows
in general, it only applies to MSVC (aka cl). (And possibly some other
unspecified (proprietary) Windows tools.)

>>>> 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.
> 
> Right.  I think VizStudio handles this by putting treating the static
> and shared libraries as different configurations; separate configs have
> separate build dirs...even if the static library and the import library
> have the same name (and it's usually up to the end user to set up
> client's -L paths to point to the correct location of those libs based
> on the desired configuration; e.g. by including ${CONFIGURATION_NAME} in
> the -L path, I believe).

One way to match that is to only allow either static or shared in one
build tree, and require two configure runs if you want both static
and shared libs, and then name the import and the static lib foo.lib
for both cases. But that seems very defensive. And not foolproof
since you get clashes if you install both build trees.

> I've seen VizStudio-built projects use several different arrangements
> for delivering these SDK-style items to end users; separate dirs, or --
> as you suggest -- separate names (usually something like
> 'foo_shared.lib')  FFTW punts completely, and ships .def files
> (instructing users to create their own import libs using the toolchain
> mechanism of their choice; obviously then, the choice of import library
> NAME is up to the end user).

Also very defensive. And no chance of working out of the box. No fun.

>>> 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).
> 
> Ah, yes, now I see.  Surely, your mechanism is a strict improvement over
> that.
> 
>>> 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.
> 
> Well, my point is, unless EVERYTHING *always* uses the compile script --
> including all autoconf (or Cmake, scons, etc etc) tests to determine
> system characteristics like "what library is installed where under which
> name" -- you will get very hard to find/fix inconsistencies in behavior.
> 
> Unless...
> 
> it doesn't matter, because the compile script and the underlying tool
> (cl.exe in this case) use the same search rules.  But if they both use
> the same search rules, then why bother implementing those rules in the
> compile script at all?  Just pass the args on verbatim to cl.exe!)

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

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.

>>>> 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.
> 
> right.
> 
>> 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.
> 
> As I mentioned above, that's the way VizStudio does it.
> 
>> But that seems very hard too, and on top of that it
>> would be a MSVC-only solution and therefore a hard sell.
> 
> Yes, IMO this would be a large architectural change to the way libtool
> operates.
> 
>> I think adding a
>> matching library search to 'compile' is the best way forward (but again,
>> not now).
> 
> Matching what?  If it matches cl.exe (e.g. cl -lfoo does the same thing
> as compile -lfoo), in terms of locating "foo.lib" -- then compile won't
> be able to "behave differently" by saying "oooh, he's linking shared,
> let me look for foo.dll.lib first...okay, there it is"...
> 
> Suddenly, `compile's behavior doesn't "match" cl.exe's.

See above, cl -lfoo doesn't work.

>> 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.
> 
> Well, that much is true.
> 
>> 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.
> 
> Agreed.

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

Cheers,
Peter