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

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

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

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

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

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

--
Chuck