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