[ 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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
