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

[Peter Rosin]

Hi Ralf!

Den 2010-09-07 22:24 skrev Ralf Wildenhues:
> * Ralf Wildenhues wrote on Tue, Sep 07, 2010 at 10:20:06PM CEST:
>> * Peter Rosin wrote on Tue, Sep 07, 2010 at 11:25:00AM CEST:
>>> Subject: [PATCH] Adjust naming of MSVC import libraries.
>>>
>>> * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [mingw, cygwin]
>>> [pw32, cegcc] <cl*, library_names_spec>: Adjust naming of the
>>> import library from foo-<major-version>.lib to foo.dll.lib, to
>>> avoid clashes with the static library for unversioned libraries.
>>> (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG) [mingw, cygwin, pw32]
>>> [cegcc] <cl*, archive_expsym_cmds>: Explicitely name the import
>>> library to match the above.
>>
>> Thanks for pushing this.  I think it deserves to be mentioned in NEWS,
>> even if MSVC wasn't supported (well) before.

I'll write something tomorrow.

> OK, thinking about it for 5 seconds longer, here's a different idea
> altogether:
> 
> why not by default disable static libraries when shared ones are
> enabled?  We do this on AIX too.  And then avoid the renaming.
> (and if --enable-static is given, disable shared)
> 
> Rationale: you don't, and can't, and won't, be able to require other
> tools to use the 'compile' script.  And you do want to be compatible
> with what MSVC does by default anyway.  And you don't want to implement
> a search algorithm in the compile script either.

That's old :-) A few messages back in the thread:

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

But what is so bad about implementing a lib search in 'compile'? Then
it's possible to work around other problems, such as -L (or rather
-LIBPATH:) only being a linker option, so I don't know if it's possible
to have different lib search paths for different libs (by adding -L
options between them). If there's a lib search in 'compile' it can feed
absolute paths to cl, effectively killing the MSVC lib search path. But
that's venturing into territory where good documentation will be needed
badly of course, and it might be a bit rich to have all that in 'compile',
that I can see. But I do think it is easier to do a perfect match between
libtool's lib search and a future 'compile' lib search, than it is to
make libtool's lib search a perfect match with MSVC. Given all the
badness that's present in MSVC, that is. (But I don't know this, I only
suspect dark corners in the land of MSVC).

If you want to move the output from a libtoolized project into some
MSVC project, you can always require the user to rename as you move
the foo.dll.lib file, or simply specify foo.dll.lib in the project
file. But agreed, random MSVC users will probably think that
foo.dll.lib looks suspicious if they have to say that in the project.

Is the lib search just out of place in 'compile'? Do you fear the
performance penalty of doing (another) scripted lib search?

I guess the list of negative issues is quite long...

> Just a thought from somebody feeling pushed by the 72 hour rule.

Sorry about that, I just didn't want to have a severely broken scheme
longer than necessary. (I don't understand how you manage to review as
much as you do, kudos to you...)

Cheers,
Peter