Question

Following the Linux from Scratch book I have managed to build a toolchain for an ARM on an ARM. This is till chapter 6 of the book, and on the ARM board itself I could go on further with no problems. My question is if I can use the prepared environment to continue building the soft from chapter 6 on my x86_64 Fedora 16 laptop? I thought that while I have all the binaries set up I could just copy them to laptop, chroot inside and feel myself as on the ARM board, but using the command from the book gives no result:

 `# chroot "$LFS" /tools/bin/env -i  HOME=/root TERM="$TERM" PS1='\u:\w\$ 
  PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin /tools/bin/bash --login +h
      chroot: failed to run command `/tools/bin/env': No such file or directory`

The binary is there, but it doesn't belong to this system:

 `# ldd /tools/bin/env 
      not a dynamic executable`

The binary is compiled as per the book: # readelf -l /tools/bin/env | grep interpreter [Requesting program interpreter: /tools/lib/ld-linux.so.3]

So I wonder if there is a way, like using proper environment variables for CC LD READELF, to continue building for ARM using these tools on x86_64 host.

Thank you.

Was it helpful?

Solution

Nope. You can't run ARM binaries on x86, so you can't enter its chroot. No amount of environment variables will change that.

You might be able to continue the process by creating a filesystem image for the target and running it under an emulator (e.g, qemu-system-arm), but that's quite a different thing.

OTHER TIPS

Yes, you certainly can chroot into an ARM rootfs on an x86 box.

Basically, like this:

$ sudo chroot /path/to/arm/rootfs /bin/sh
sh-4.3# ls --version 2>&1 | head
/bin/ls: unrecognized option '--version'
BusyBox v1.22.1 (2017-03-02 15:41:43 CST) multi-call binary.

Usage: ls [-1AaCxdLHRFplinsehrSXvctu] [-w WIDTH] [FILE]...

List directory contents

    -1  One column output
    -a  Include entries which start with .
    -A  Like -a, but exclude . and ..
sh-4.3# ls
bin       css       dev       home      media     proc      sbin      usr       wav
boot      data      etc       lib       mnt       qemu-arm  sys       var

My rootfs is for a small embedded device, so everything is BusyBox-based.

How is this working? Firstly, I have the binfmt-misc support running in the kernel. I didn't have to do anything; it came with Ubuntu 18. When the kernel sees an ARM binary, it hands it off to the registered interpreter /usr/bin/qemu-arm-static.

A static executable by that name is found inside my rootfs:

sh-4.3# ls /usr/bin/q*
/usr/bin/qemu-arm-static

I got it from a Ubuntu package. I installed:

$ apt-get install qemu-user-static

and then copied /usr/bin/qemu-arm-static into the usr/bin subdirectory of the rootfs tree.

That's it; now I can chroot into that rootfs without even mentioning QEMU on the chroot command line.

No you cannot, at least not using chroot. What you have in your hands is a toolchain with an ARM target for an ARM host. Binaries are directly executable only on architectures compatible with their host architecture - and x86_64 is not ARM-compatible.

That said, you might be able to use an emulated environment. qemu, for example, offers two emulation modes for ARM: qemu-system-arm that emulates a whole ARM-based system and qemu-arm that uses ARM-native libraries to provide a thinner emulation layer for running ARM Linux executables on non-ARM hosts.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top