This is the mail archive of the cygwin-apps 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 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
file:

(lib2.la depends on lib1.la):

dependency_libs=' =/mingw/lib/lib1.la =/mingw/lib/lib1.la'
libdir='/mingw/lib'

(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
confuse libltdl?

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>_HOST="i686-pc-linux-gnu"
> <NAMESPACE>_PREFIX="/usr/local"  # defaults to /mingw or /usr
> inherit <namespace> [...]
> 
> The only question is what to use for <namespace>?

DEPLOY ?

DIST?

--
Chuck


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