Re: Extend libtool dll namespaces for mingw-w64

[JonY]

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

Hi

My proposal has the same rationale as using the "cyg" and "lib" prefix
on Cygwin and MinGW, so no DLLs can clash. The issue is that libtool
uses the "lib" prefix for both 64bit and 32bit DLLs, and for both mingw
and mingw-w64.

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

This has nothing to do with Windows naming schemes, DLLs can be named
anything, including with a .so extension. This has to do with libtool
DLL naming schemes. I'm working to prevent DLLs from overwriting each
other, especially on install for multilib gcc.

Are you suggesting that DLLs are to be installed to /lib32 and /lib64
instead of bindir? That way, DLLs won't clash, to a certain extent.

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

PATH is irrelevant when DLLs with the same name overwrite each other on
mulitlib GCC installs, so you end up with a copy of whatever that was
last installed.

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

It may skip paths when encountering DLLs of the wrong bitness on Win64,
not so on Win32, where it fails automatically when encountering 64bit
versions of 32bit DLLs with the same name. mingw.org DLLs having the
same name with 32bit mingw-w64, making things even more complicatd,
both are 32bit, but compatibilities not guaranteed, especially with
SJLJ vs DW2 libstdc++-6.dll.