This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport patch: suppress libtool fixup step

On 7/8/2010 1:23 PM, Dave Korn wrote:
On 06/07/2010 19:56, Charles Wilson wrote:

To deal with the duplicated DLLs from two different multilib mingw64
toolchains (one that supports -m32 and -m64, but *defaults* to -m64, and
one that also supports -m32 and -m64, but *defaults* to -m32), the DLLs
are actually installed into a completely different directory outside the
$triple area.

The 64bit dlls are moved manually to $special_prefix/bin64/ and
$special_prefix/bin32 -- because these DLLs are "shared" by both
toolchains in the specificed -mXX mode, so the "deep" directory inside
one toolchain's private area or the other, are both inappropriate.

In what way are these DLLs "shared"? They are target libraries, they aren't linked into the cross-compiler itself, and applications built by the cross-compiler don't link directly against the DLLs anyway, they have import libs.

I guess the term 'shared' is not exact. Rather, consider the following scenario:

1) There exists a mingw64-based gcc, that while defaulting to 64bit mode, is multilib and supports also -m32. When it is built, you will get two copies each of (e.g.) libstdc++-sjlj-6.dll, libstdc++.dll.a, libstdc++.a, and

One of these sets will be 32bit, and the other will be 64bit.

Now, the .la, .a, and .dll.a will all live in
   $prefix/lib/gcc/x86_64-w64-mingw32/VER/      << for 64bit
   $prefix/lib/gcc/x86_64-w64-mingw32/VER/lib32 << for 32bit
since we usually build with --enable-version-specific-runtime.

e.g. $(toolexeclibdir). This is as it should be.

2) Suppose there also exists a separate mingw64-based gcc. Only this one defaults to 32bit (it may or may not also be multilib and support -m64; that's unimportant here).

When building this compiler, you will get a set of 32bit libs, libstdc++-sjlj-6.dll, libstdc++.dll.a, libstdc++.a, and (If it is multilib, you may also get another matching 64bit set).

Now, in this case the .la, .a, and .dll.a will all live in
   $prefix/lib/gcc/i686-w64-mingw32/VER/      << for 32bit
   $prefix/lib/gcc/i686-w64-mingw32/VER/lib64 << for 64bit, if multilib
since we usually build with --enable-version-specific-runtime.

e.g. $(toolexeclibdir). This is as it should be.

3) Now, if we want to have a *single* consolidated location for the $target DLLs -- so that you can actually RUN the stuff you build, without a very odd set of $PATH settings -- where should those DLLs go?

The original idea was that there would be a special /bin32 and /bin64 directory for them. This has since been refined to a custom "sysroot" a la' fedora:

   /usr/sysroot/mingw64-32/bin/  (A)
   /usr/sysroot/mingw64/bin/     (B)

Into (A) would go all the DLLs that are 32bit: the ones from
AND the ones from

Similarly, into (B) would go all the DLLs that are 64bit: the ones from
AND, if the nominally 32bit mingw64 compiler is also multilib, the ones from

But...assuming the nominally 64bit but multilib mingw64 compiler, and the nominally 32bit (multilib?) compiler have the same version, then you will have TWO identical DLLs living at the same location.

Our setup.exe doesn't allow this, and it's bound to cause issues. So the idea was that JonY would pick ONE of each pair as the "blessed" one, to be delivered in the (e.g.)


package, and in the


package. So, even though you have two compilers that might be thought to "own" that installation package, there is only one such package for each duplicated DLL, and that package is "shared".

But...this is all handled manually, after 'make install'.

I think it would be cleaner if the right -bindir settings were sent to libtool during the build/install process. This is PR40125(*), btw. Which I'm down to fix, I guess I'd better get on with it.

Well, yes...I agree with Doug Semler that by default, the -bindir argument should be $(toolexeclibdir) and not $(bindir) for cross builds.

That would be nice and clean, and would be similar to how .so's are normally treated on linux IIRC. It also makes the most sense for $host=not-cygwin, $target=mingw* cross compilers.

I'm just arguing that for the *specific* case where $host=cygwin and $target=mingw* (e.g. we know that the underlying platform ALSO supports running the "target" executables and DLLs), that as a cygport packaging step -- NOT part of gcc's own internal build or install process -- the DLLs should be "plucked" from $(toolexeclibdir) and put into a common location, which by *policy* on cygwin would be

"the $(special_prefix)/bin/ directory, where $(special_prefix) is the value that shall be passed as --prefix= when building cygwin-deployed packages whose contents are compiled using $host=cygwin, $target=mingw* cross compilers"

And the corresponding .la files munged appropriately (again, as a cygport postinstall step, not part of the gcc install process per se).

Whether $(special_prefix) is ALSO passed when building the cross compiler itself as --sysroot or --build-sysroot, I don't know.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]