What is the state of CMLFS methods for cross-compiling?

[takusuman]

Recently or, to be more specific, yesterday, I decided to make a build of Copacabana with LLVM/clang, and I would like to know if this project already runs on ARM and i{4,5,6}86.
I'm inclined to cooperate if needed, like I did in 2021 at the original Musl-LFS.

[dslm4515]

I am successful on x86_64. I'm revising the LLVM 15.0.6 build/branch for the last time before upgrading to 16.0.6.

I've attempted a 32bit build (i686) but hit a snag while compiling python3 for the final system: built python locks up the the system and will not finish the build...even if I left it over night. Cgnutools and llvmtools work as intended.... tricky as LLVM seems to use i386 built is for i686... kind of like Musl Libc.

With the release of Raspberry Pi, I'm getting my pi4 ready to build a aarch64 build.

[takusuman]

I've attempted a 32bit build (i686) but hit a snag while compiling python3 for the final system: built python locks up the the system and will not finish the build...even if I left it over night.

What is your CPU? This sounds more like a CPU bug to me.
Already tried to compile it in a virtual i386? Like 86Box or even QEmu.

With the release of Raspberry Pi, I'm getting my pi4 ready to build a aarch64 build.

Well, have you already got anything from ARM/aarch64? Just out of curiosity.

Another question: how is the performance of this? Is it really worse than GCC built Musl-LFS as some LLVM haters say? And how could I measure it by myself?

[dslm4515]

What is your CPU?

Intel Core Duo T2600 in an old HP Compaq nc6400. I then tried resuming the build on an old mini-iTX board that has an Intel Atom N2800...but ran the chroot in 32-but mode. Same issue. Build hangs on ./python -E ./setup.py build.

[takusuman]

What is your CPU?

Intel Core Duo T2600 in an old HP Compaq nc6400. I then tried resuming the build on an old mini-iTX board that has an Intel Atom N2800...but ran the chroot in 32-but mode. Same issue. Build hangs on ./python -E ./setup.py build.

That's really strange, maybe it's not your CPU fault. Maybe we should try contacting the Python development team?

[dslm4515]

My amd64 build is 36 packages behind my i686 build... I will see if there was a mistake in the i686 build or if the same issue shows up in the amd64 build.

I have found my RPi4 but not sure if it can still boot from the USB(3.0)-SATA 2.5" SSD it has.

[dslm4515]

Finished python3 for the final system in my amd64 build: No issues.
Looks like there is a problem with my 32-bit build OR I need to make adjustments for 32-bit x86.

[takusuman]

Looks like there is a problem with my 32-bit build OR I need to make adjustments for 32-bit x86.

I wish I had a i{3,4,5,6}86 hanging around so I could test this out, but for now I'm only going with x86_64 for Copacabana.
May I try building it via 86Box later just for fun and see if I can find something out.

[dslm4515]

Per CLFS, you could build i686 on a x86_64 machine via 'setarch' or a kernel module:

If your host has a tool called setarch, this may solve your problems, at least if you're building for i686. On an architecture such as x86_64, using "setarch linux32 uname -m " will only ever output i686. It is not possible to get an output of i486 or i586.

or even "Uname Hack":

The Uname Hack is a kernel module that modifies the output of uname -m by directly changing the value of the detected machine type. The kernel module will save the original value and restore it when the module is unloaded.

[dslm4515]

I built llvmtools for i686 on a amd64 machine then used setarch with chroot to enter a "32-bit" chroot environment.

[dslm4515]

I have completed an i686 build on an x86_64 host. Biggest issue was stage 2 python3 compiles but stalls with any python script like pip. Workaround for it was building stage 2 python with stage1 clang instead of stage 2.

I am now doing another i686 build on another x86_64 to clean up the repo and verify it works.

For "non-similar" cross builds, like arm64 on a x86_64 host most likely will need a different build method. I probably will create another repo like ... xCMLFS?

[takusuman]

May I try building it via 86Box later just for fun and see if I can find something out.

Pardon for not giving any return yet, I have been a little bit busy on other projects beside Copacabana --- but on which it depends --- and I couldn't test any of the hypothesis that you made yet.

[dslm4515]

No problem! My MLFS repo is getting stale as the last few months have I havetaken a break (built some plastic models, gunpla, in my free time instead of updating my repos) and started working on updating CMLFS.

[takusuman]

For "non-similar" cross builds, like arm64 on a x86_64 host most likely will need a different build method. I probably will create another repo like ... xCMLFS?

Why? How much would it differ from building from one platform to itself?

[dslm4515]

Say, I want to build CMLFS for a Raspberry Pi 4 on my x86_64 host.

I would have to build a cross-toolchain (cgnutools) that runs on x86_64 but produces binaries that run on aarch64. Of course, a binary built for aarch64 cannot run natively on a x86_64 CPU. I would have to run some sort of emulation on my x86_64 host to run aarch64 code. This is not needed for i686/x86_64 as x86_64 CPUs can run 32-bit code (usually most Linux kernels have support to run 32-bit code on 64-bit x86 CPUs).

Then cgnutools would be used to build llvmtools that runs on aarch64 and produces binaries for aarch64. Again, I will need some sort of emulation to run llvmtools on my x86_64 host.

Therefore for "non-similar" cross-builds, I would have to deploy some sort of emulation, such as QEMU (run a virtual machine) or binfmt-support.

There is Cross-LFS, but it relies on booting a minimal LFS system on hardware that supports the target CPU architecture:

Booting is required when you are compiling for a different architecture, such as building a PowerPC system from an x86. The rule of thumb here is that if the architectures match and you are running the same series kernel (specifically, a 2.6.32 or newer Linux kernel) you can just chroot. If you aren't running the same series kernel, or are wanting to run a different ABI, you will need to use the boot option.

[takusuman]

I would have to build a cross-toolchain (cgnutools) that runs on x86_64 but produces binaries that run on aarch64. Of course, a binary built for aarch64 cannot run natively on a x86_64 CPU. I would have to run some sort of emulation on my x86_64 host to run aarch64 code.

Oh, I was aware of this, but can we cross-build it all instead of breaking it in two stages or the way a Linux system is built forbids us? Like was done on SunOS, for instance, where it was entirely cross-built from one platform for another if needed.

Again, I will need some sort of emulation to run llvmtools on my x86_64 host.

QEmu could be a good shot, but, correct me if I'm erred, maybe an ARM-specific emulator can perform better for cross-compiling an entire system than QEmu.

I'll be studying some of this since I'm with some free time lately.