libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extend libtool dll namespaces for mingw-w64


From: Ralf Wildenhues
Subject: Re: Extend libtool dll namespaces for mingw-w64
Date: Thu, 28 Jan 2010 06:46:16 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

* 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.
> 
> For example, both mingw and mingw-w64 builds libstdc++-6.dll from GCC.
> When installed, there might be up to 3 incompatible versions of
> libstdc++-6.dll, from mingw.org, 32bit mingw-w64 and 64bit mingw-w64.

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.

> I suggest the following naming scheme.

I suggest we follow whatever naming scheme Windows uses.  Including none
if none.  GNU libtool certainly shouldn't choose its own flavor.

> libtool should also check if GCC "-m32" or "-m64" is used, and select
> the proper namespace accordingly (mingw-w64 GCC can do multilib).

No, the developer should have her $PATH set correctly.

What does the Windows kernel do if it finds a needed shared library of
the wrong ABI early in $PATH while trying to start a program?  Fail or
skip, and if skip, silently or verbosely?

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]