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 Thu, 2010-07-15 at 12:50 -0500, Yaakov (Cygwin/X) wrote:
> 2) Cygwin-to-other cross-compiling, via cross.cygclass
> 
> Cross-compiling is supported for packages using autotools, cmake, or
> hand-written makefiles.  Packages are automatically "installed" into the
> sysroot (under $D).

The way I used the sysroot so far was to configure packages for their
regular prefix (/usr or /mingw), then install with DESTDIR=
${D}${CROSS_SYSROOT}.  Without the sysroot path hard-coded anywhere, the
cross-compiled files should be usable either on the host system as-is or
within the sysroot for further cross-compiling.

Unfortunately I found two problems with this approach: libtool and
*-config scripts (NOT pkg-config).

libtool's ignorance of sysroots is well documented and seems to be
considered a known bug.  I've seen it manifested in at least two ways:

1) on ELF platforms, during relink; in linux-i686-glib2.0, libgio
consistently refused to relink because a spurious -L/usr/lib caused
Cygwin's libc.a to be picked up.  The offending -L flag was caused by
the line in libtool following the words "we'll fake it", triggered by
relinking against libglib and friends from the same package, which
libtool thought would literally reside in /usr/lib.

2) when building setup.exe, libtool complained that it could not
find /mingw/lib/libgpg-error.la, a dependency_libs of libgcrypt.  Of
course, libgpg-error was there, under the sysroot.  (Note that I
manually fixed my mingw-libgcrypt test build to not interfere with the
setup.exe/gcc-4.5 discussion.)

The other problem would be packages relying on a foo-config script to
discover foo's cflags/libs, which would be prone to output -I or -L
flags for the native path instead of within the sysroot.  Note that
pkg-config can understand sysroots through an environment variable,
which cross.cygclass uses.

The alternative to mitigate these issues would be to configure with
--prefix=$CROSS_SYSROOT$prefix et. al., causing the sysroot to be
hard-coded throughout.  This should fix these cases, but packages so
built would be unsuitable for use on the host system, and using
host-built packages under the sysroot would require adding the sysroot
to their .la and .pc files.

Thoughts?


Yaakov



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