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: JonY
Subject: Re: Extend libtool dll namespaces for mingw-w64
Date: Fri, 29 Jan 2010 09:10:32 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0

On 1/29/2010 04:07, Ralf Wildenhues wrote:
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.


Hi,

this has nothing to do with the libc runtime linker, this has to do with preventing possible DLL conflicts on Windows for DLLs with potential ABI difference.

I get "No menu item `win32' in node `(ld.info)Top'." for info ld WIN32.
Do you mean --dll-search-prefix? If so it can be easily extended as
well.

ld doesn't really have anything to do with runtime DLL resolving. The import lib determines what DLL names the executables will look for.

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


Yes, GCC trunk uses that, but right now, -bindir for both 32bit and
64bit subsystems point to the same dir.

Another solution it to stop installing DLLs to bindir and follow unix
style installs into libdir, right beside the import libs, let the user
set the PATH. That way, we don't need a bin32 and bin64 directory, but
it does not prevent possible conflicts with 32bit mingw-w64 and
mingw.org DLLs.




reply via email to

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