I'm wanting a second opinion on this before I start dedicating my time on this. Anyways, I'm wanting to go through the LFS book however instead of compiling for x86_64 / amd64 I would be compiling for aarch64 but using a x86_64 host. I would also like to do PowerPC, RISC-V, etc. but I want to prove out I can do it for aarch64. So I've figured out how to chroot once I get past ch. 5 (Basically using qemu-system / binfmt to chroot into a foreign filesystem.). So the only question I have, is it possible to build ch. 5 for aarch64? I would assume all I would have to do is set LFS_TGT to "aarch64-lfs-linux-gnu". (Plus some small deviations from the book.)

I know I will have to deviate a bit in chapter 5. due to when you compile gcc you will have to change some flags around to get gcc compiled for aarch64.

Note I've already ventured into cross compiling but it got to the point where it feels janky and there's a worry I might contaminate the sysroot / chroot with host libraries.

Have you tried CLFS? It has the grunt work done. Personally, the idea sounds like a black hole for spare time to me, but a great learning exercise, I suppose.

BTW, the kernel supports a variety of weird & wonderful architectures. Some are cpu cores designed by FPGA manufacturers for Lock-in purposes. The idea was: You buy Xilinx FPGAs, and they'll allow you use their cpu core on them. Many were added in the 1990s; Things have moved on in the real world, and linux support for the rest of the system (Beyond kernel,glibc, gcc & binutils) may be very weak indeed.

To try those LFS versions, you'd have to design, build & program at least an FPGA from each manufacturer. Are you up to that? Can you pay someone to do it? That's not a cheap undertaking.

That wouldn't work, because you would need a a Chapter 5 toolkit that already ran on aarch. That means having a prior stage to create those tools from x86. That's how CLFS does it. You first create a set of very basic tools, not the complete Chapter 5 toolset but only the essentials. That means binutils, gcc, glibc and one or two packages that gcc uses internally like file and zlib. You compile them for your fictitious build-compatible host but with the real final architecture as target. That means they will run on your current x86 machine but compile for aarch. Then you use this toolset to build the real Chapter 5 toolset. Those will be aarch programs that won't run on your current machine. You will need to add whatever you need to boot on the new machine unless you're going to chroot from an existing Linux system there. Then you tar it up, untar it on the other machine and run Chapters 6-7.

Being honest, I can see you doing arm, which I think LFS does or has done. For most of the others, development has stopped while the versions roll on in Arm & x86. You should test the water by seeing what basic programs you can get for the other systems. I believe there has been at least one request to delist the h8300 from the kernel on grounds like lack of supporting software, kernel won't compile, and the h8300 doesn't exist anyhow.

I have been toying with this OP idea for the last few weeks. I recently bought a Rock64 (rk3328 aarch64) w/mali 450 gpu for $20. I have Arch arm on it and Manjaro arm. I have KDE Plasma running wayland-egl. Working doesnt mean it's right though. Needs to have it's own image not a generic one like all the linux distro's use on their arm offerings. That led me to go for my own hand built cross compiler using Arch as my base. Most of the distro's have a pkg set for aarch64 cross compiler on bare metal. And that's the catch. Bare metal.

Most arm dev work is done on qemu not bm. Once you have the cc in /opt or /usr you can begin doing cross-lfs and or embedded lfs but the books are quite old and not ready for arm64. Google is almost useless too. I composed an email and sent it to clfs-support mail if anybody wants to join in with me on this endeavor. Send a mail to show your support and interest for this to happen on cross-lfs. All for fun and maybe we can get an up to date cross-embedded book for arm64 out of the efforts.

PS Hazel is correct on the way it gets done in essence. Dont think biz-kid understands current bm cross compiling very well. Kernels 5.2.x currently support my rock64.

This comment below is not true at all.

Why do you need to cross-compile? Can't you just do a native compilation in aarch?

[QUOTE-arch-linq]Dont think biz-kid understands current bm cross compiling very well. Kernels 5.2.x currently support my rock64. [/QUOTE]

It certainly looks that way, doesn't it? In fact, I completely misread the Original Post and answered the wrong question. My bad.

WHy CC vs native? Speed mainly. Take llvm, the kernel or whole qt5-everywhere-5.14.0 for example. Would take days and days for just those 3 pkgs to build natively. My goal is to install arm the same way one installs LFS. Document it and share it.

1 members found this post helpful.

Yes I have, though its a bit out of date. I'm actually taking inspiration from Ataraxia Linux as a base (Using glibc instead of musl.)

Yup it seems that is correct. Thought it over a little more and it seems its not possible. I'll just wing it and go for cross compiling like CLFS.

Moin,

I did something like this some months ago. Yes, it worked somehow.
But it was really nasty. CLFS seems to be rather dead, and not support aarch64 - so i started somehow with CLFS and then slowly migrated back to the LFS-Book before chrooting, resulting in multiple builds of tools, lacking tools and lots of hassle. But in the end i got some rootfs, which seemed to behave nicely, when i chroot into it on a xilinx ultrascale+ platform.
For the building i used some x64 (older i3) system with a static qemu-aarch64 binary and the binfmt magic. But this is pretty slow - as expected. I was surprised, that "uname" worked OK in the qemu chroot. This is something, where i rembembered to have difficulties in the past (a couple of years ago, i already tried that for an arm926 and failed).

Gruss
WK