Re: Extend libtool dll namespaces for mingw-w64

[Ralf Wildenhues]

[ Dave, this is
  <http://thread.gmane.org/gmane.comp.gnu.libtool.general/10723>;
  see at the end for a quick GCC-related question ]

Hello,

first off, I completely agree with Tor's reply to your message.
Adding a couple of bits:

* JonY wrote on Thu, Jan 28, 2010 at 11:06:50AM CET:
> On 1/28/2010 13:46, Ralf Wildenhues wrote:
> >* JonY wrote on Tue, Jan 26, 2010 at 04:26:32PM CET:
> >>Currently, on Win32 platforms, Cygwin uses the "cyg" prefix for dlls,
> >>and MinGW based systems uses the "lib" prefix.
> >>
> >>This works fine, until mingw-w64 showed up with 64bit dlls. This
> >>problem is especially apparent with trying to build mingw-w64 cross
> >>compilers.
[...]
> >MinGW and MinGW64 should cooperate on issues like this.  Libtool has
> >little to no bearing here, except to follow.  Libtool cannot decide what
> >the runtime system will load.

> My proposal has the same rationale as using the "cyg" and "lib" prefix
> on Cygwin and MinGW, so no DLLs can clash.

No, that is not the same thing.  The Cygwin runtime system actually
looks for libraries named cyg<NAME>.dll; see 'info ld WIN32'.  The
GNU libc runtime linker has builtin functionality to look for different
variants and ABIs of a certain library, to do multi-ABI on x86_64 and
elsewhere.  None of this maps to the issue at hand.

I suggest that a very practical solution is to simply keep 32bit and
64bit executables in different $(bindir) directories.  The current git
Libtool allows you to specify the -bindir in which the DLLs are supposed
to end up.  I know that svn trunk of GCC uses that, but I'm not sure if
it is used to put 32bit DLLs in another place than 64bit ones.  It might
be good to check that before the 4.5 release.  (CC:ing Dave).

> The issue is that libtool
> uses the "lib" prefix for both 64bit and 32bit DLLs, and for both mingw
> and mingw-w64.

Cheers,
Ralf