cygport cross-compiling beta1

Charles Wilson cygwin@cwilson.fastmail.fm
Fri Jul 23 02:50:00 GMT 2010


On 7/17/2010 4:26 PM, Charles Wilson wrote:
> I'll post more after I use the new tools to build the various non-core
> packages that exercise the cross.cygclass, such as linux-ncurses,
> mingw-bzip2, etc. I'll address issues with libtool/pkgconfig at that
> time, as well (short version: our version of pkgconfig claims to support
> sysroot via $PKG_CONFIG_SYSROOT_DIR, but newer versions have supposedly
> improved that support.  Also, there was one patch, and another promised,
> on libtool-patches addressing just this issue, in the last week).


OK, so the libtool stuff is still percolating. Paolo just posted his
patch series earlier today, so I haven't had a chance to test it out
yet. However, it APPEARS after a cursory glance to work like this:

1) you configure stuff with --prefix=${CROSS_SYSROOT}${prefix}
2) libtool, when generating the .la file, observes all of the various -L
and -R options.  It recognizes when each argument starts_with $sysroot,
and does the following:
    a) replaces the original argument to -L and -R with the value
       sans $sysroot.
    b) stores the value of the sysroot as a separate variable in the
       .la file.
3) Then, when *using* the .la file, you pass a new '-sysroot' option
   to libtool. That tells libtool to reconstruct the original
   $sysroot$prefix path.  OTOH, if you *don't* pass -sysroot, then
   the normal operation ensues -- and since $sysroot has been stripped
   from all -L and -R arguments, operation is "native".

I've seen absolute paths to other objects buried in .la files (e.g.
without -L options; e.g.
   deplibs=/usr/long/path/to/buried/prefix/lib/libfoo.la.
I don't know how Paolo's patch deals with that, if
   $sysroot=/usr/long/path/to/buried

But...as I read the proposal, you *would* want to configure with
--prefix=$sysroot$prefix.  I think.

Now, maybe there is something I'm not seeing, but it sure seems to me
that the better solution is to configure with --prefix=$prefix, and then
add support for $sysroot on the back end, instead of configuring with
$sysroot$prefix and trying to strip out references to $sysroot on the
front end.

The reason I think this is, I'm concerned about *hardcoding* the
$sysroot$prefix values into the compiled binaries! (e.g. 'strings
foo.exe | grep $sysroot' might return non-empty, and that would be bad,
when foo.exe is deployed on the $host system in $prefix.


But...this is all just my guess based on inspection of the code; I
haven't been able to test it yet.

Ditto WRT pkg-config.  I plan to simply update our pkg-config to the
latest upstream, and see if that helps wrt $PKG_CONFIG_SYSROOT_DIR.


One thing I thought of; if you want to run foo-config scripts from
/usr/i686-pc-mingw32/sys-root/mingw/bin during configure, then you
pretty much have to set $PATH so that $sysroot$prefix/bin precedes your
own /usr/bin -- otherwise, you'd get /usr/bin/foo-config.

But...what if you're creating a REAL, full sysroot.  Like, with
coreutils and everything, over there in $sysroot$prefix/bin.  Do you
REALLY want the cross-$host version of 'uname' to precede your own?


Probably not.  I'm not sure what the "right" answer here is, except
maybe for packagers to arrange so that munged copies of any foo-config
scripts are placed in /usr/$host/bin (or, if that scares you, then
/usr/$host/scripts/).  That way, the foo-configs in $sysroot$prefix/bin
are usable only once deployed onto the cross $host under $prefix, but
the ones in /usr/$host/scripts are usuable on the $build system.

I think that's probably easier than patching every package that ships a
foo-config, so that foo-config accepts a -sysroot option.  But...a patch
adding a -sysroot option to a foo-config would probably be accepted by
the upstream maintainers of foo.


========================

Now, as far as using the cross.cygclass to build non-core stuff.  Using
my original mingw-{zlib,bzip2,xz,gpg-error,gcrypt} cygports and Yaakov's
versions, I've created local versions of all those packages using the
new tools and the i686-pc-mingw32 compiler.

It all seemed to go pretty smoothly; my cygports are still uglier than
Yaakov's, but that's partly because I was trying to maintain strict
one-for-one compatibility with the old versions (mgwbz2_1.dll names, and
all).  Later on, we might think about breaking backwards compat on those
packages (esp. the DLLs, since nobody uses them yet) and make "ours"
more normal, and the cygports more clean.  But not yet.

Of course, I also brought over all my .hints and .READMEs; these are
"real" packages, not proof-of-concepts (even if I may have to rebuild
them all again anyway, once the official mingw.org-based cross compiler
is released).

Here's the key bit: using these packages, I was able to build a working
setup.exe using both i686-pc-mingw32-g++, and g++-3 -mno-cygwin (without
resorting to setup-no-autoload.patch).

Here's how I did it:

1) mingw-gcc compiled with:

CYGCONF_ARGS="
        --disable-multilib
        --disable-sjlj-exceptions
        --enable-lto
        --enable-languages=c,c++,fortran,objc,obj-c++
        --enable-libgomp
        --enable-version-specific-runtime-libs
        --disable-win32-registry
        --with-dwarf2
        --localedir=/usr/${TOOLCHAIN_TARGET}/share/locale
"
I had a mingw-pthread available so --enable-libgomp DID have an effect.
 However, as noted previously, --localedir did NOT.


I also recompiled mingw-runtime (new-style), mingw-w32api, and
mingw-pthreads using the new gcc.  However, I didn't take any care to
ensure that -mms-bitfields was used.


2) For ALL of the mingw-{zlib,bzip2,xz,gpg-error,gcrypt} packages, I
made sure that each was compiled with -mms-bitfields.  All of the
*-mingw32-* packages shipped by mingw.org are built that way, even
though it is not the default for the compiler.

I really think it ought to BE the default for *mingw32*, but that train
has long left the station.



3) I also *linked* all of the DLLs and EXEs in these packages using
-shared-libgcc.  This has no effect on the setup.exe test, but I mention
it for thoroughness.


4) I linked setup.exe with -static-libgcc, naturally.


5) I, too, had to manually modify
   /usr/i686-pc-mingw32/sys-root/mingw/lib/libgcrypt.la
in order to link setup.exe, but that is a
libtool-doesn't-understand-sysroot-yet problem:

 # Libraries that this one depends upon.
-dependency_libs=' -L/mingw/lib /mingw/lib/libgpg-error.la'
+dependency_libs=' -L/mingw/lib
/usr/i686-pc-mingw32/sys-root/mingw/lib/libgpg-error.la'


6) I used Yaakov's setup-gcc45.patch to start with, but in order to
ensure that setup's .o objects were all compiled with -mms-bitfields, I
had to extend his changes (see attached; apply after setup-gcc45.patch).


Now, with all of those changes, setup.exe worked.  However, if I
compiled setup.exe using i686-pc-mingw32-gcc WITHOUT -mms-bitfields,
then I got an 0xc0000005 error.


The other interesting bit was, using these mingw-{...} packages, and a
little bit of magic, I was able to compile a working setup.exe using
gcc-3 -mno-cygwin.  I'll describe how that worked in another message, as
it has implications for how we manage the rollout of the mingw.org-based
cross compiler and the (semi-)retirement of gcc3.


I've attached the cygport and patches for these five packages here.


--
Chuck
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chucks-doconfigure-updates.patch
Type: application/x-patch
Size: 790 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20100723/bea1cc08/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chuck-mingw-cygport-examples.lzma
Type: application/octet-stream
Size: 41868 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20100723/bea1cc08/attachment.obj>


More information about the Cygwin-apps mailing list