Re: Extend libtool dll namespaces for mingw-w64

[Tor Lillqvist]

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

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

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

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

--tml