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/6/2010 3:48 AM, Yaakov (Cygwin/X) wrote:
On Mon, 2010-07-05 at 13:27 -0400, Charles Wilson wrote:
JonY needs to suppress the "libtool fixup" postinstall step when
packaging the mingw64 gcc.  He may or may not need to fixup his .la
files, BUT -- given that we're talking about gcc here, AND his cross
compiler goes somewhere other than /'s likely that whatever
"fixing up" he needs to do, will be specific to that package and likely
unable to re-use the more generic fixup code.

I am working on proper cross-compiler support within cygport now:

* cygconf handling of build/host/target;
* modifying the libtool fixup for different targets;
* handling conflicting files between native and cross-compiler/ed
packages (to allow prefix=/usr).

That is EXCELLENT (regardless of the answer to the question below). Thanks!

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?

Regarding libtool fixups: am I correct that on mingw32/64 platforms,
deep non-module libs still need to be relocated to remove the ../bin
(IOW put the DLL alongside the .la)?

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.

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.

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.

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.


-- Problem reports: FAQ: Documentation: Unsubscribe info:

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