This is the mail archive of the
mailing list for the Cygwin project.
Re: cygport cross-compiling beta1
On 7/22/2010 8:47 PM, Yaakov (Cygwin/X) wrote:
> On Tue, 2010-07-20 at 00:53 -0400, Charles Wilson wrote:
>> Why shouldn't cygport allow that?
> Thinking about this further, I think the problem is that we're talking
> about two entirely different use cases:
> 1) cross-compiling a package to install into the sysroot, to be used
> solely on Cygwin for cross-compile other software, which would follow
> Cygwin packaging guidelines and use the system-default prefix;
> 2) cross-compiling software for use on another system (along the lines
> of canadian-cross.cygclass), which would follow the *host*'s packaging
> guidelines, or that of the user (at least wrt prefix).
> These are two completely different scenarios and in order to cover both
> of them w/o confusion, I think we should handle them separately,
> particularly if (as I suspect) we are forced to prepend $CROSS_SYSROOT
> to $prefix for case (1).
My early tests with Paolo's libtool patches look promising. You
configure with --prefix=$prefix (not sysroot), and libtool takes care of
the rest. When libtool detects a cross build sysroot situation, you
basically end up with a magic pattern in the deplibs variable of the .la
(lib2.la depends on lib1.la):
dependency_libs=' =/mingw/lib/lib1.la =/mingw/lib/lib1.la'
(Also, -L and -R entities are similarly munged, to include the '='
marker for sysroot builds)
When linking, libtool doesn't warn about "relocations" because it knows
about sysroots. It all seems to work on the $build system as expected.
My concern -- which I haven't tested -- is three-fold:
1) what happens when an old libtool sees that '=/path" pattern? Do all
clients need to have an updated libtool, in order to be built against
the libs even on the $build machine?
2) Can you deploy these .la's on the $host machine for futher, native
development? How does libtool deal with the magic '=' symbol, when you
DON'T have a sysroot are are building a client using a native compiler,
against a lib that was built elsewhere using a cross compiler?
3) So, you build a product that uses libtool modules for dynamic
loading, and it needs the .la files so that libltdl can do its thing.
Will module .la's have this '=' symbol in them? If so, will that
More testing to do...
> So how about this: leave cross.cygclass to handle case (1), since that
> was what it was originally designed for, and make a new cygclass for
> case (2), sort of like a generalized canadian-cross.cygclass (which
> would be removed). The API would look something like:
> <NAMESPACE>_PREFIX="/usr/local" # defaults to /mingw or /usr
> inherit <namespace> [...]
> The only question is what to use for <namespace>?