brendlefly62 Apprentice


Joined: 19 Dec 2009 Posts: 161
|
Posted: Tue Apr 22, 2025 4:11 pm Post subject: [solved] crossbuild environment for binhost |
|
|
After OP, I answered my own question. The problem described below arose because I was applying an incomplete mix of strategies to operate inside chroot. On the one hand, as advised in the cross build environment wiki article referenced below, I was trying to use an alias (emerge-chroot) to override the "ROOT=/usr/${TARGET}" setting in the crossbuild environment's make.conf, but it seems that make.conf's PKGDIR and DISTDIR settings were not being adjusted by the "emerge-chroot" alias. So, I have since made the alias more explicit about that. I've also linked the chroot's /usr/${TARGET}/var to its /var directory (like the wiki article advises one to do for PORTAGE_TMPDIR) to ensure PKGDIR and DISTDIR are also really in the right place... Here's the chroot's new /etc/bash/bashrc.d/emerge-chroot --
Code: | #alias emerge-chroot="ROOT=/ CBUILD=$(portageq envvar CHOST) HOSTCC=$CBUILD-gcc emerge"
alias emerge-chroot="\
ROOT=/ \
CBUILD=aarch64-unknown-linux-gnu \
PORTAGE_TMPDIR=/tmp/ \
DISTDIR=/var/cache/distfiles \
PKGDIR=/var/cache/binpkgs \
PORT_LOGDIR=/var/log/portage \
HOSTCC=aarch64-unknown-linux-gnu-gcc \
emerge" |
I've been playing with this on and off for several years but recently took it up again and discovered something I missed earlier --
Working on an x86_64 (amd64) workstation with lots of RAM and CPU, I am setting up a cross-build environment with e.g. Code: | TARGET=armv7a-unknown-linux-gnueabihf |
i.e. the cross build environment is located at /usr/${TARGET}/ in the host workstation's file system/
I have very carefully followed Gentoo wiki guides to set up crossdev (https://wiki.gentoo.org/wiki/Crossdev) and a cross build environment with qemu chroot (https://wiki.gentoo.org/wiki/Cross_build_environment). I notice the warning at the top of the latter that it might need to be updated, and I have not managed to get cross-${TARGET}/rust-std to work (so skipping that for now).
I carefully noticed where the system creates binpkgs, and it seems logical when I'm "just" using the crossdev toolchain to run e.g. Code: | ${TARGET}-emerge -uavDN @system --keep-going | Binary packages built this way end up in the host workstation's filesystem at /usr/${TARGET}/var/cache/binpkgs. I have a link at /var/www/localhost/htdocs/packages/ Code: | armv7a-unknown-linux-gnueabihf-rpi23A-packages -> /usr/armv7a-unknown-linux-gnueabihf/var/cache/binpkgs | So those packages are available to bihhost clients. (all good so far).
As the cross build environment wiki article notes, not all packages can be built this way -- some have to be built natively, so I've followed that guide's process for setting up a qemu chroot. This includes setting up an alias for use in the chroot Code: | alias emerge-chroot="ROOT=/ CBUILD=$(portageq envvar CHOST) HOSTCC=$CBUILD-gcc emerge" | I found this use of portageq to set CHOST and CBUILD to be unrelaiable, so I modified the alias to explicitly reference the TARGET, e.g. Code: | alias emerge-chroot="ROOT=/ CBUILD=armv7a-unknown-linux-gnueabihf HOSTCC=armv7a-unknown-linux-gnueabihf-gcc emerge" | Note: this logically specifies ROOT=/ inside the chroot...
Also, the crossbuild environment make.conf (host filesystem /usr/${TARGET}/etc/portage/make.conf contains the following
Code: | CHOST="armv6j-unknown-linux-gnueabihf"
CBUILD=x86_64-pc-linux-gnu
ARCH="arm"
# use this for cross-building
ROOT=/usr/${CHOST}/
# use this for chroot (or carefully use alias emerge-chroot to specify ROOT, CBUILD)
#ROOT=/ | Which I have manually used to set CBUILD and ROOT in the past, but it is my impression that the intent of the alias is to override these make.conf settings when building in the chroot. Is this correct?
This seems to "work" in that I can emerge the rest of the system with e.g. Code: | (armv7a chroot) hostname / # emerge-chroot -uavDN @system |
HOWEVER - I have noticed that it is putting the binpkgs and distfiles that it builds this way inside the chroot's /usr/${TARGET}/var/cache/ directory -- i.e. on the host workstation, they are located at /usr/${TARGET}/usr/${TARGET}/var/cache/
Is this normal behavior inside the chroot, or do I have some environment variable set wrong?
I noticed that the cross build environment article instructs Quote: | Create the Portage temporary directory:
Code: | ln -s /tmp /usr/armv6j-hardfloat-linux-gnueabi/tmp |
|
Do I need to do something like that for the chroot's /var also?
That would point the chroot's /usr/${TARGET}/var --> /var which should map it correctly for the host workstation's filesystem -- but I want to know if that is an appropriate solution or more of a work-around, when a more basic solution should have fixed it |
|