alternative to fchroot

[sputnik]

Not a criticism or to belittle Drobbins hard work, but I have been doing this for years with a simple bash script.  If you haven't seen his video on fchroot on the forum here and don't know what it does search for fchroot.

I simply keep 2 bash scripts in ROOT directory of any device I want to use it with, navigate to that directory (mounted via NFS)  from the BIG BOY computer and run 1st one script to enter the QEMU chroot, the other to cleanup when exiting.  Here's an example from my odroid C1+, armv7a:

#MOUNTDIRS - script name
mount -t proc none proc
mount --rbind /sys sys
mount --rbind /dev dev
mount --bind /dev/pts dev/pts
mount tmpfs -t tmpfs -o rw,nosuid,nodev,noexec dev/shm
mount --bind /tmp tmp
cp /etc/resolv.conf etc
echo ""
echo "don't use pump"
echo 'env -i HOME=/root TERM=$TERM DISTCC_HOSTS="star,cpp,lzo joshua,cpp.lzo mrpink,cpp,lzo micah,cpp,lzo localhost" MAKEOPTS="-j8" chroot . /bin/bash -l'

# UMOUNTDIRS - script name
umount proc
umount -l sys
umount -l dev/pts
umount -l tmp
umount dev/shm
umount -l dev
umount tmp

That's it!  The 1st script echoes some reminders to me and the exact line to chroot in, I just copy & paste it (the script can't run that line directly).  This is a particularly good example because I also set some environment variables on the way in, shows that.

Of course you must set up your makefile as drobbins states, in my case:

QEMU_SOFTMMU_TARGETS="i386 arm"
QEMU_USER_TARGETS="i386 arm"

And install qemu.  Finally, you must run /etc/init.d/binfmt either in rc-update (bootup) or add starting/stopping it to the scripts.

I find it mainly handy for things that overwhelm the whopping 1G ram on the odroid, it'll work but it's s...l...o...w.  If at all possible it's much faster to use the cross-compile SYSROOT method, search on the web for "gentoo cross-compile", you'll find it.  Unfortunately it doesn't work with many packages, particularly the intensive ones you'd like to use it on.  One notable exception is LLVM.  The odroid can't build it anymore as of a couple of years ago, but I found a trick to build it natively on the powerful machine and output a 32 bit arm package in minutes.  Last time I used the qemu chroot method it was > 10 hours on a core2.  Here are my notes:

****WARNING!!!  DO NOT DO THIS, THERE IS A PROBLEM, READ BELOW****

# LLVM trick notes:
# 1.  you must have same version already installed on the compile machine

# 2.
in $SYSROOT/etc/portage/profile/use.mask, put a file that has this in it:
abi_x86_64
llvm_targets_X86

# 3.  you must have libffi installed:
armv7a-hardfloat-linux-gnueabi-emerge libffi  

type:
ABI_X86="" LLVM_TARGETS="BPF ARM" armv7a-hardfloat-linux-gnueabi-emerge -BO llvm:<version>
probably just this now:
LLVM_TARGETS="BPF ARM" armv7a-hardfloat-linux-gnueabi-emerge -BO llvm:<version>

#5.  Check out the package.env stuff for llvm, see llvm.conf

ENJOY!

# ${SYSROOT}/etc/portage/package.env

sys-devel/llvm					notmpfs.conf nodistccccache.conf llvm.conf

# ${SYSROOT}/etc/portage/env/llvm.conf
ABI_X86=""
CMAKE_EXTRA_CACHE_FILE=/usr/armv7a-hardfloat-linux-gnueabi/etc/portage/env/cmake_cache_files/llvm.cmake

# ${SYSROOT}/etc/portage/env/cmake_cache_files/llvm.cmake
SET (CMAKE_INSTALL_LIBDIR "lib" CACHE STRING "" FORCE)
SET (LIB_SUFFIX="" CACHE STRING "" FORCE)
SET (LLVM_TARGETS_TO_BUILD "ARM;BPF" CACHE STRING "" FORCE)
SET (LLVM_LIBDIR_SUFFIX "" CACHE STRING "" FORCE)
SET (FFI_LIBRARY_DIR "/usr/armv7a-hardfloat-linux-gnueabi/usr/lib" CACHE STRING "" FORCE)
SET (FFI_INCLUDE_DIR "/usr/armv7a-hardfloat-linux-gnueabi/usr/lib/libffi-3.2.1/include" CACHE STRING "" FORCE)

THE PROBLEM: This indeed makes the package in arm-32 bit format, but later I found it is linked to lib64, non-existent on the arm.  In my case, the odroid does just fine with it for my uses and I'm sure that can be remedied with CMAKE_OPTIONS, but since I have no problem I haven't worked on it.  I skipped Funtoo 1.3 on the odroid, when 1.4 is released I'll update to that and get to the bottom of a solution on it.  It makes a package which you can then install natively on the arm with emerge -K.  Hmm, it's been so long, maybe I did fix that lib problem, maybe that's why it JUST WORKS®.  I dunno...try it at your risk...

I used to build my arm kernels with the SYSROOT method, but nowadays I find that pump distcc on the native device is just as fast and easier.  Here's the basic script for doing such a thing, minus the dracut and mkimage operations:

export SYSROOT=/usr/armv7a-hardfloat-linux-gnueabi
armv7a-hardfloat-linux-gnueabi-emerge odroidc1-sources #custom amlogic kernel
# cd usr/src/linux
# ${SYSROOT}/usr/bin/xkmake menuconfig
# cd ${SYSROOT}

KERNEL_VERSION=-$(readlink ${SYSROOT}/usr/src/linux|cut -d'-' --complement -s -f1)
cd ${SYSROOT}/usr/src/linux
${SYSROOT}/usr/bin/xkmake -j3
${SYSROOT}/usr/bin/xkmake -j3 modules
${SYSROOT}/usr/bin/xkmake -j3 INSTALL_MOD_PATH="/mnt/nfs/odroid" modules install
${SYSROOT}/usr/bin/xkmake -j3 uImage
cp ${SYSROOT}/usr/src/linux/arch/arm/boot/uImage  /mnt/nfs/odroid/mnt/sdcard/storage/uImage.funtoo
cp ${SYSROOT}/usr/src/linux/arch/arm/boot/dts/meson8b_odroidc.dtb /mnt/nfs/odroid/mnt/sdcard/storage/meson8b_odroidc.funtoo.dtb

Just a rough guide there to show what can be done.

The gentoo cross-compile info tells you to use xkmake rather than make when using the cross-compile ${SYSROOT} method.  Here's my ${SYSROOT}/usr/bin xkmake file for the odroid:

#!/bin/bash
make ARCH="armv7a" CROSS_COMPILE="armv7a-hardfloat-linux-gnueabi-" INSTALL_MOD_PATH="${SYSROOT}" $*

My 2 cents worth...