I've adjusted the glibc ebuild to be able to cross-compile it in a prefix. Problems were: - ${EPREFIX} is missing in a couple of places - glibc does not build on a case-insensitive FS such as HFS+ - when installing only headers the ebuild forces configure to use the host toolchain *and* overrides some checks, effectively promising stuff about the target to configure which the host toolchain must be able to provide. In case of OS X the host toolchain differs so significantly from the target toolchain that configure chokes on it. I've changed that to check if we do have a target toolchain already. If so, it is used for configure so that at least we can do a two-stage bootstrap of glibc using "crossdev --without-headers -s2" and then in a second step "crossdev -s4" Reproducible: Always
Created attachment 434452 [details, diff] Fix ebuild to work in prefix
Created attachment 434454 [details, diff] Make glibc compile on case-insensitive FS
Hi Michael. Thanks for the report! The Prefix part has been merged into mainstream Gentoo. For the case-insensitive FS support, could you please forward it upstream? Keep on good work. *** This bug has been marked as a duplicate of bug 473728 ***
I've re-raised case-insensitive fs support upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=72.
Hi Benda, are you sure you've got the equivalent of this bit because that's what's really hurting cross-compilation on OS X (i.e. forces configure to use the host toolchain *and* overrides some checks, effectively promising stuff about the target to configure which the host toolchain must be able to provide - with this change we use the target toolchain if present already and thus can do a --s1+--without-headers -> --s4 two-phase bootstrap): @@ -183,6 +183,8 @@ mkdir -p "${builddir}" cd "${builddir}" + export CC="$(tc-getCC ${CTARGET})" + if ! $CC -v >/dev/null ; then # if we don't have a compiler yet, we cant really test it now ... # hopefully they don't affect header geneation, so let's hope for # the best here ... @@ -217,6 +219,8 @@ einfo " ${v}" export ${v} done + export CC="$(tc-getBUILD_CC)" + fi # Blow away some random CC settings that screw things up. #550192 if [[ -d ${S}/sysdeps/mips ]]; then @@ -250,7 +254,6 @@ # So forcing CC/CFLAGS is sane. set -- "${S}"/configure "${myconf[@]}" echo "$@" - CC="$(tc-getBUILD_CC)" \ CFLAGS="-O1 -pipe" \ CPPFLAGS="-U_FORTIFY_SOURCE" \ LDFLAGS="" \
(In reply to Michael Weiser from comment #5) > Hi Benda, are you sure you've got the equivalent of this bit because that's > what's really hurting cross-compilation on OS X (i.e. forces configure to > use the host toolchain *and* overrides some checks, effectively promising > stuff about the target to configure which the host toolchain must be able to > provide - with this change we use the target toolchain if present already > and thus can do a --s1+--without-headers -> --s4 two-phase bootstrap): > > @@ -183,6 +183,8 @@ > mkdir -p "${builddir}" > cd "${builddir}" > > + export CC="$(tc-getCC ${CTARGET})" > + if ! $CC -v >/dev/null ; then > # if we don't have a compiler yet, we cant really test it now ... > # hopefully they don't affect header geneation, so let's hope for > # the best here ... > @@ -217,6 +219,8 @@ > einfo " ${v}" > export ${v} > done > + export CC="$(tc-getBUILD_CC)" > + fi > > # Blow away some random CC settings that screw things up. #550192 > if [[ -d ${S}/sysdeps/mips ]]; then > @@ -250,7 +254,6 @@ > # So forcing CC/CFLAGS is sane. > set -- "${S}"/configure "${myconf[@]}" > echo "$@" > - CC="$(tc-getBUILD_CC)" \ > CFLAGS="-O1 -pipe" \ > CPPFLAGS="-U_FORTIFY_SOURCE" \ > LDFLAGS="" \ This logic should be controlled externally with CROSSCOMPILE_OPTS="headers-only". Testing CC inside glibc complicates the ebuild.
> This logic should be controlled externally with > CROSSCOMPILE_OPTS="headers-only". Testing CC inside glibc complicates > the ebuild. Yeah, but that's exactly where crossdev fails: It builds glibc with headers-only and glibc.ebuild runs configure with lots of preset configure cache variables, promising stuff about the target system and the toolchain. If we cross-compile, it's pure luck that this works when build host and target are similar enough. On the Mac that's not the case and we really do need to prefer the target toolchain if it's available to get anywhere. IMO the same will happen when more people switch to clang on Gentoo Linux.
Created attachment 512128 [details, diff] Adjust ebuild to work in prefix Hello Benda, thanks to your work on prefix and crossdev the number changes necessary to cross-compile from Darwin/macOS to Linux has gone way down. The attached adjustments to the glibc ebuild are still necessary for me though. Could you have a look at them again? - cross_eprefix(): use prefix for host paths when cross-compiling, install into $EPREFIX/usr/$CTARGET instead of /usr/$CTARGET - noncross_eprefix(): use prefix for target paths only when not cross-compiling, glibc files install in $EPREFIX/usr/$CTARGET/{bin,lib,usr/include} instead of $EPREFIX/usr/$CTARGET/$EPREFIX/{bin,lib,usr/include} - use cross toolchain for headers-only if available. I have looked into CROSSCOMPILE_OPTS="headers-only" as you suggested but can for the life of me not see how it would simplify handling the problem. - patch for case-insensitive fs as before. Upstream is not responding. With these changes I can build a cross toolchain targetting Linux in a prefix on Darwin as well as then cross-compile glibc into the target root without any prefix (or with one as desired using --prefix to emerge as suggested in https://bugs.gentoo.org/586438). I have also tested this on amd64-linux in a native system as well as a RAP and non-RAP prefix in native and cross mode and found no problems. Thanks, Michael
Thanks, re-opening this bug for further consideration.
(In reply to Benda Xu from comment #9) > Thanks, re-opening this bug for further consideration. Feel free to attach a patch against glibc-9999.ebuild ...
I no longer need this functionality, so will close. Thanks for your help!
