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 libstdc++.la.
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 libstdc++.la.
(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
$prefix/lib/gcc/x86_64-w64-mingw32/VER/lib32
AND the ones from
$prefix/lib/gcc/i686-w64-mingw32/VER/
Similarly, into (B) would go all the DLLs that are 64bit: the ones from
$prefix/lib/gcc/x86_64-w64-mingw32/VER/
AND, if the nominally 32bit mingw64 compiler is also multilib, the ones from
$prefix/lib/gcc/i686-w64-mingw32/VER/lib64
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.)
mingw64-m32-libstdc++6-VER-REL.tar.bz2
package, and in the
mingw64-m64-libstdc++6-VER-REL.tar.bz2
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.
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
