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