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

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

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

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

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

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

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

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

--
Chuck