Re: Extend libtool dll namespaces for mingw-w64

[JonY]

On 1/28/2010 19:30, Tor Lillqvist wrote:
> > The issue is that libtool
> > uses the "lib" prefix for both 64bit and 32bit DLLs, and for both mingw
> > and mingw-w64.
>
> Well, my take is that except for people working on the *tools
> themselves* (meaning gcc, binutils etc), this is not really a problem.
> Sure, libtool is a tool used by developers, but the end result, DLLs,
> are intended to be used by end-users running applications.
>
> I see two cases. 1) On 32-bit Windows, no end-user should in a normal
> scenario be having 64-bit binaries anyway. (End-users use installers,
> which surely should check whether the OS is a 64-bit one before
> installing 64-bit binaries. If somebody is unzipping some random
> archive containing 64-bit DLLs onto his 32-bit system and setting up
> PATH to include them, they aren't really end-users but wannabe hackers
> doing stuff they really don't understand. One can't protect against
> people like that.)
>
> Case 2) On 64-bit Windows, it's fine to have in PATH two instances of
> a DLL with the same name, one being 32-bit and the other 64-bit. The
> runtime loader will load the correct one when some other module (exe
> or dll, 32- or 64-bit) requires it.

Hi,

With DLLs named differently, they simply can't clash, however hard you
try, idiot proof as well, no more messing with PATH.

Distributing for end-users is never a problem, as long as they don't try 
to be idiots and mix dlls with similar names for different archs.

> > 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.
>
> That is then something gcc's configury should be fixed to handle.

Yes, GCC uses libtool to handle most target lib linking and installing,
which leads us back to libtool's --mode=install, or --mode=link,
depending on the fix method.

GCC make install currently installs both 32bit and 64bit dlls to the
same /bin, unless we switch to the UNIX'ish convention of installing
shared libraries to /lib{,32,64}, the problem remains because 2 dlls
installing into the same /bin.

> > It may skip paths when encountering DLLs of the wrong bitness on Win64,
>
> That is indeed my impression too. (Please, let's try to avoid using
> the convenient, but wrong, term "Win64". The Win32 API can be either
> 32- or 64-bit. Using "64-bit Windows" is not that much more verbose.)
>
> > not so on Win32, where it fails automatically when encountering 64bit
> > versions of 32bit DLLs with the same name.
>
> Yeah, but as I said above, my opinion is that such a situation with
> 64-bit DLLs present on a 32-bit Windows is an anomaly that in reality
> occurs only on machines of *developers* working on cross-builds of the
> MinGW toolchain itself, or cross-builds of other software. Such people
> should just know what they are doing. And if the build mechanism of
> some software incorrectly makes it so that the OS tries to use
> cross-built binaries not intended for the build system, that is the
> problem of the build mechanisms of the software in question. Not a
> libtool problem.

As I said earlier, you can't have the DLLs installed properly at all,
they overwrite each other on install, there is also the problem of
trying to redistribute the DLL that has been overwritten. This happens
even on Linux hosted mingw-w64 multilib toolchains.

There are currently 2 ways of solving this to allow more than 1 
toolchain on Windows:

1. Stop installing DLLs to bindir, DLLs are to be installed following 
Unix-ish conventions into libdir. This has the nice effect of moving
multilib DLLs to their respective libdirs, users will need to take care
of the PATH env themselves. However, doesn't stop 32bit mingw-w64 built
DLLs from clashing with mingw.org versions.

2. Change the DLL prefixes. This way, binaries can continue with
installing into /bin, with no possibility of clashing.

> ===>>  I guess my main point is:<<===
>
> This is in no way unique to cross-building from 32-bit Windows to
> 64-bit Windows. You can't say from the name of an ELF shared object as
> produced by libtool what architecture it is for either.
>
> Or do you suggest that libtool should start using a platform triplet
> specific prefix in *all* instances instead of just "lib"?

There is no problem with Linux .so files, the Linux dynamic library
loader handles this problem gracefully because .so files live in
libdir (lib{,32,64} respectively).

Windows DLLs OTOH are installed always to bindir, unlike Linux .so 
files, so they clash.

Cygwin's way of working around this is to use the "cyg" prefix for
Cygwin DLLs, so provided mingw.org versions of libraries do not clash
with Cygwin versions.

I am extending this idea for mingw-w64, I can't see why we can't use the
l32/l64<name> namespace, incompatible DLLs should have different names.
The "lib" prefix is already used by mingw.org.

Yes, having the platform triplet in the DLL name is fine too, as long as 
it does not clash with existing namespaces.