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: Possible cygport bug with cross compiles


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


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