Possible cygport bug with cross compiles
Charles Wilson
cygwin@cwilson.fastmail.fm
Wed Sep 1 15:15:00 GMT 2010
On 9/1/2010 1:44 AM, Yaakov (Cygwin/X) wrote:
> On Tue, 2010-08-31 at 17:34 -0400, Charles Wilson wrote:
>> When testing JonY's mingw64 compiler, I found that often the include
>> files ended up in the wrong directory.
>
> Often?
As in, the ones that inherit toolchain are fine. The ones that inherit
cross are not; they put the include files under
.../sys-root/mingw/${host_triple}/include rather than the location
expected by the compiler, which is .../sys-root/mingw/include --- and
therefore, need the "extra" rule in src_install.
>> mv ${D}${CROSS_PREFIX}/${CROSS_HOST}/* ${D}${CROSS_PREFIX}
>
> The reason for that is the *upstream* mingw-w64 Makefiles install to
> $prefix/$host/{include,lib}, based on the pre-sysroot convention; so if
> we want to use the sysroot for *everything*, including the system
> headers, then they end up in $CROSS_PREFIX/$CROSS_HOST/{include,lib} and
> need to be moved thereafter.
Sorry, I was confused because my mingw64-zlib seemed to behave like the
mingw64.org packages -- hence, not a "mingw64.org"-specific problem, but
rather a cygport problem (e.g. what's the common link between these
packages: they each are built by cygport, and inherit cross).
However, zlib -- when building on mingw-ish using the autotool driven
build process rather than scripts/makefile.mingw -- is an odd duck.
I tried again with xz -- which is not an odd duck -- and it worked fine.
CROSS_HOST="x86_64-w64-mingw32"
ORIG_PN="xz"
inherit cross
DESCRIPTION="liblzma for MinGW-w64 Win32 (64bit) toolchain"
HOMEPAGE="http://tukaani.org/xz/"
SRC_URI="http://tukaani.org/xz/xz-${PV}.tar.xz"
So, it turns out the ACTUAL problem (with zlib) is that I need to fix my
buildsys patches to zlib, which enable using the autotool build system
for cygming. Never mind.
> IOW this could be seen as an issue with the mingw-w64 sources, not
> cygport. OTOH, mingw-w64 is not unique; both newlib and avr-libc are
> coded to install into $prefix/$host/{include,lib}; glibc and mingw.org
> install correctly into sysroot OOTB. A possible solution is to
> reconsider to what degree we use the sysroot.
No, sys-root is the best idea since sliced bread!
Now that the libtool sysroot stuff has been merged upstream, I'm about
to release an updated libtool for cygwin and mingw.org. This may be a
bit premature (2.2.12 is due out RSN) but I've already delayed two or
three weeks longer than I originally wanted.
The installed-on-$build .la files will have the '=' markers, but updated
libtool scripts will know how to ignore them if they are copied without
change onto a native $host. OTOH, not even updated libltdl will know
how to deal with those elements, yet, if the .la files are used to load
modules.
However, libtool (the script) now also supports taking .la files as
arguments to mode=finish, and will fix that up for you.
So, the procedure would be --
1) copy your files to a staging area for packaging, so that they can
be installed on $host
2) package them up, with a postinstall script or step that invokes
libtool mode=finish <list the .la files>
where the path to each .la file is the final on-$host path to
the .la files in their installation location.
This is not an uncommon procedure, at least on ELF platforms, I think.
Even today, if you build a library with a non-standard $prefix and want
to create an RPM or DEB, you need to invoke
libtool mode=finish <the dir where libraries are installed>
as part of your package's postinstall process. If you want to be
strictly correct, that is.
Now, this isn't something cygport needs to worry about -- unless cygport
was *executed* itself on linux, using a linux->cygwin cross compiler, to
generate packages to be installed on cygwin.
>> I'm not real sure about the ${prefix%/...} manipulation, either,
>> especially for cross. (The effect of this manipulation for a cross for
>> $host=mingw is not apparent, since $prefix doesn't actually end in /usr
>> in that case). But...the current code seems to be incorrect, IMO.
>
> The point is that (per FHS) if prefix=/usr, then sysconfdir=/etc
> (NOT /usr/etc) and localstatedir=/var (NOT /usr/var), However, if
> prefix != /usr (e.g. /mingw), then these should also go under the prefix
> (/mingw/etc and /mingw/var). The same goes for cyginstall.
You're right, for native builds where prefix is actually /usr or /other.
I was concerned about the 'cross' case, where prefix ends up being
${CROSS_SYSROOT}/usr or ${CROSS_SYSROOT}/mingw (that is, ends-with
rather than starts-with /usr or /mingw) -- and I misread the
substitution. (I should know by now to ALWAYS explicitly test what %,
%%, #, and ## do in bash var substs, I can never remember exactly how
they each behave...)
Sorry for the false alarm.
--
Chuck
More information about the Cygwin-apps
mailing list