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-22 at 22:41 -0400, Charles Wilson wrote: 
> 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}

Not according to his sysroot.at (patch 5/8).  He adds a new configure
option, so you configure with --with-sysroot=${CROSS_SYSROOT} --prefix=
${prefix}.

> 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.

If $sysroot needs to be prepended to $prefix, then that strengthens the
argument for considering cross-compiling-for-sysroot and
cross-compiling-for-host two separate use cases.

> 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?

No, but packages such as coreutils which only provide programs don't
belong in a sysroot.  The purpose of a sysroot is for libraries which
you use to cross-compile other software which depend on them.

But for this very reason, adding $sysroot$prefix/bin to PATH is
unhelpful at best and maybe even dangerous.  If a package's configure
depends on a foo-config script, then it should provide a way to specify
the path to that script, by passing either a --with-foo-config=$sysroot
$prefix/bin option or FOO_CONFIG=$sysroot$prefix/bin value to configure.

And no, I'm not about to start inventing paths or moving files around
either.

> 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.

Not necessarily, and requiring a patch for every single package which
ships a foo-config is less than ideal.

This is, as I noted earlier, the other area which makes configuring
without $sysroot in $prefix difficult.  They are prone to adding -I and
-L flags which will point to the native root instead of the sysroot,
which will break the build at link time at least, if not earlier.

If the libtool patch is accepted (and that's an if, given upstream's
track record on patch review), and this remains the only other issue to
using --prefix=$prefix, then perhaps adding a cross_sysrootize()
function which will do the trick:

src_install() {
   cd ${B}
   cyginstall

   cross_sysrootize ${D}${CROSS_SYSROOT}/usr/bin/foo-config
}

where cross_sysrootize essentially does:

for f in $@; do sed -i -e "s|\([^t]\)$prefix|\1$CROSS_SYSROOT$prefix|g"
$f; done

(the leading [^t] to avoid paths which somehow already had sys-root)

AFAICS from the *-config scripts I have in /usr/bin, that would appear
to do the trick w/o breaking anything, but it would need some testing.

> 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.

Those "mgw" prefixes need to GO AWAY.  Period.  NOW is the time to fix
these DLL names, when were anyway completely changing mingw support,
because they were wrong to begin with.  Cross-compiled sysroot libraries
must always be compatible with the native versions in name and ABI,
otherwise you completely defeat the purpose.

> 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.

If mingw.org is using it for its packages then so must we; that's part
of ABI compatibility after all.

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

What about adding it to mingw*-gcc specs?  If not, then I'll have to add
it automatically to CFLAGS and friends.

JonY, what about mingw-w64?  Are you using -mms-bitfields as well?

> 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.

BTW, isn't that supposed to be the default?  Why isn't libgcc showing up
as a dependency of anything C?

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

Using -Wc,-static instead of -Wl,-static (part of my patch) takes care
of that automatically.

> 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.

Which is worse then I got doing everything w/o -mms-bitfields but using
autoload.  But that's not surprising: once you start building with
-mms-bitfields then *everything* needs to use it.


Yaakov



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