Re: [gentoo-alt] Compiling package in Prefix with ROOT and no EPREFIX

[Michael Weiser]

Hi list,

On Thu, Apr 07, 2016 at 08:43:17PM +0200, Michael Weiser wrote:

> As was to be expected, I'm now faced with the fact that all packages I
> compile *for* the target and install into ROOT=EPREFIX/usr/CTARGET get
> compiled for a Prefix in EPREFIX on the target and thus install into
> ROOT/EPREFIX.

> Is there a way to build a package in Prefix with ROOT set and EPREFIX
> unset?

As feedback on this I can report that I now have a prefix on my MacBook
Air running OS X 10.11 that is not only able to build and install cross
toolchains for arm*-{soft,hard}float-linux-gnueabi, avr and
powerpc-unknown-linux-gnu but also cross-compile and merge packages for
those targets into $EPREFIX/usr/$CTARGET ready for deployment to an
actual system (as of yet untested for real though)!

On the embarassing side it turns out that all that was missing was
basically a turned on brain on my part: After configuring
$EPREFIX/usr/$CTARGET/etc/profile/make.conf and colleagues for the
target system and switching to the emerge-$CTARGET wrapper provided by
crossdev, it almost worked. Bug
https://bugs.gentoo.org/show_bug.cgi?id=586438 gave the final hint of
providing --prefix=/ to emerge-$CTARGET to disable all prefix logic for
the cross compile target.

When actually doing the cross-compiling, about 50% of packages need
tweaking to cope with the fact they're configured on a non-Linux system
for a Linux system.  Most annoyingly, glibc, linux-kernel, linux-headers
and in consequence iptables are hit by file name collisions due to
filesystem case-insensitivity (e.g.
/usr/include/linux/netfilter/xt_DSCP.h vs. xt_dscp.h - whoever thought
having those file names and have them include each other (!) was a good
idea).

Bugs pertaining to cross-compile support in prefix (on OS X):

https://bugs.gentoo.org/show_bug.cgi?id=586726: sys-devel/crossdev: prefixify
https://bugs.gentoo.org/show_bug.cgi?id=583202: sys-devel/binutils-config: Extend ldwrapper to work with cross-toolchains
https://bugs.gentoo.org/show_bug.cgi?id=583210: cross-*/binutils: QA notice invalid self-reference install_name/reference to
https://bugs.gentoo.org/show_bug.cgi?id=583216: sys-libs/glibc: Fix cross-compilation in prefix
https://bugs.gentoo.org/show_bug.cgi?id=583432: toolchain.eclass: Adjust for cross-compilation in prefixo

for reference:
https://bugs.gentoo.org/show_bug.cgi?id=583198: cross-arm*/gcc: nesting level exceeded when compiling cross compiler for arm with clang
https://bugs.gentoo.org/show_bug.cgi?id=586438: sys-apps/portage: Only enable prefix QA checks when prefix USE flag is active

What's still needed is some config in /etc/portage to glue this all
together. What I now have looks like this:

- inject bracket depth workaround for clang to compile gcc for arm via env snippet
- replace kernel and elibc use flags of build system (Darwin) with those for the
  target (Linux) ones
- do not set CC=clang and CXX=clang++ in make.conf but have a bashrc for
  portage that conditionally sets them based on the target we're compiling
  for. Also tweak {C,CXX,LD}FLAGS based on the same logic. This is only
  needed for bootstrapping the cross toolchain because this is done with
  the build host portage config. Actual emering of packages for the target
  then uses the separate make.conf in $EPREFIX/usr/$CTARGET.

All this should only be needed on OS X (or in a Linux prefix using
clang). A prefix on Linux should generally be much more forgiving
because build and target systems are much more similar.

env/clang-fbracket-workaround:
CFLAGS_armv5teb_softfloat_linux_gnueabi="-fbracket-depth=1024"
CFLAGS_armv5tejl_softfloat_linux_gnueabi="-fbracket-depth=1024"
CFLAGS_armv7ve_hardfloat_linux_gnueabi="-fbracket-depth=1024"
CFLAGS_armv7veb_hardfloat_linux_gnueabi="-fbracket-depth=1024"

package.env/system 
cross-armv5teb-softfloat-linux-gnueabi/gcc clang-fbracket-workaround
cross-armv5tejl-softfloat-linux-gnueabi/gcc clang-fbracket-workaround
cross-armv7ve-hardfloat-linux-gnueabi/gcc clang-fbracket-workaround
cross-armv7veb-hardfloat-linux-gnueabi/gcc clang-fbracket-workaround

profile/package.use.force/system 
cross-avr/gcc -kernel_Darwin -elibc_Darwin kernel_linux elibc_glibc
cross-armv5tejl-softfloat-linux-gnueabi/gcc -kernel_Darwin -elibc_Darwin kernel_linux elibc_glibc
cross-armv5b-softfloat-linux-gnueabi/gcc -kernel_Darwin -elibc_Darwin kernel_linux elibc_glibc
cross-armv7ve-hardfloat-linux-gnueabi/gcc -kernel_Darwin -elibc_Darwin kernel_linux elibc_glibc
cross-armv7veb-hardfloat-linux-gnueabi/gcc -kernel_Darwin -elibc_Darwin kernel_linux elibc_glibc
cross-powerpc-unknown-linux-gnu/gcc -kernel_Darwin -elibc_Darwin kernel_linux elibc_glibc

profile/package.use.mask/system 
cross-avr/gcc -kernel_linux -elibc_glibc kernel_Darwin elibc_Darwin
cross-armv5tejl-softfloat-linux-gnueabi/gcc -kernel_linux -elibc_glibc kernel_Darwin elibc_Darwin
cross-armv5teb-softfloat-linux-gnueabi/gcc -kernel_linux -elibc_glibc kernel_Darwin elibc_Darwin
cross-armv7ve-hardfloat-linux-gnueabi/gcc -kernel_linux -elibc_glibc kernel_Darwin elibc_Darwin
cross-armv7veb-hardfloat-linux-gnueabi/gcc -kernel_linux -elibc_glibc kernel_Darwin elibc_Darwin
cross-powerpc-unknown-linux-gnu/gcc -kernel_linux -elibc_glibc kernel_Darwin elibc_Darwin

You get the idea. bashrc attached.

Thanks to everyone who's connected to creating these awesome pieces of
software I can grab and glue together into something even more awesome
like this. I'm a very happy cross-compiling prefix-camper now. ;)
-- 
bye, Michael
Don't panic!