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


Problem reports:
Unsubscribe info:

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