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