Mail Archives: cygwin/2010/07/06/18:28:52
On Tue, 2010-07-06 at 14:56 -0400, Charles Wilson wrote:
> There are a couple of ways the term "cross-compiler support" could be
> interpreted.
>
> 1) support using cygport to compile packages using a cygwin-based cross
> compiler ($host=cygwin, $target=?). E.g. mingw-zlib built using
> i686-pc-mingw32-gcc.exe. (or, for that matter, cross-compilers for some
> other $target)
>
> 2) support using cygport to create cygwin packages that provide the
> cross-compiler toolchains themselves
>
> 3) support using cygport on a linux $host, to create cygwin packages
> from a linux-host cygwin-target cross environment.
>
> Which of the three interpretations best describes your current effort?
(1) and (2), as both are needed for mingw64. (3) is something
completely unrelated, nor am I sure how practical it would be (but I'm
not ruling it out yet, as I haven't thoroughly looked at it).
> Err...yes and no.
>
> Ordinarily, yes: that's where the build -- as patched -- puts them. And
> that's probably what the default cygport ought to do, *in general*.
> However...
>
> 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.
Why exactly do we need both, and why would one want a x86_64 compiler
that defaults to i686? We are supposed to get a i686-pc-mingw32
cross-compiler one of these days, isn't that enough for the 32-bit side
of things?
> 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.
I'm not sure that I agree, but I'll deal with this when I respond on
cygwin-apps with a proposed patch for cygport.
> But...this is all handled manually, after 'make install'.
>
> So...yes, cygport should probably act as you specify, and then
> mingw64-gcc's cygport script will come along afterwards and further
> manipulate things.
Then I will proceed in that fashion for *-*-mingw* hosted DLLs, and skip
them for other hosts.
> I still think that the ability to completely *suppress* libtool fixups
> is needed in general, both until the the cross-compile-supporting
> version reaches public release, and even afterwards, possibly.
I have yet to see a single legitimate case for not using libtool fixups
for PE hosts.
Yaakov
--
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
- Raw text -