Cross-compiling qemu for aarch64 failed, damaged system

nameiwillforget · n00b Joined: 07 May 2024 Posts: 37

I'm setting up portage on my desktop so I can use it to cross-compile packages for my Raspberry Pi 4. I've been following the wiki and got to the part where you recompile qemu for the target architecture:

pingtoo · Posted: Thu Jul 04, 2024 8:57 pm Post subject:

nameiwillforget,

What do you like to archive ?

There are multiple issues in your post, it is unclear of what really cause.

for example your qemu emerge code

nameiwillforget · n00b Joined: 07 May 2024 Posts: 37

Pingtoo,

I must have copied the wrong command in my post, what I meant is probably "arm64". I'm a bit confused as to when I should use "aarch64" and when to use "arm64" but I'm pretty sure I've figured it out now.

After I tried to copy the bin, sbin, lib and lib64 directories from my backup into my main system, I could no longer execute any commands in sbin. After I tried to do a few more things to repair my system I had completely broken it and had to restore it from my backup. Luckily, the backup was recent and not too much harm was done. Anyway, I tried to set up cross-compiling again, this time deleting the lib subfolder of the cross-compile system immediately and replacing it with a symlink to its usr/lib instance to avoid that the system is set up as a usr-split system, and this time I got further and even managed to set the chroot up, but only in the directory noticed that portage didn't compile during the initial package compilation, as well as gcc and other essential packages. The problem starts by the fact that Net-SSLeay doesn't compile. Here are the outputs of the program compilation:

pingtoo · Posted: Fri Jul 05, 2024 1:41 pm Post subject:

nameiwillforget,

everything looks alright to me for the build command, but however the actual build system seems to pick up CFLAGS from somewhere outside of Portage (may be it is from your host system?)

It could be a bug in the dev-perl/Net-SSLeay. I will need to do some research for this. (Might take a little bit of times because I don't have X86 environment, will need to use Riscv to simulate)\

In the mean time could you try another package? just to test if you got same error (where gcc got wrong CFLAGS) if this is true, then the problem is system level else it is islotate in dev-perl/Net-SSLeay.

Hu · Administrator Joined: 06 Mar 2007 Posts: 22684

I recall seeing somewhere that Perl had a bad habit of memorizing the CFLAGS into its module build system, then using them on every Perl module built later. I was not aware this extended to it trying to reuse host CFLAGS on a cross-compile, but that is what appears to be happening here.

nameiwillforget · n00b Joined: 07 May 2024 Posts: 37

I just tried emerging btop and it worked. During the setup I had for a time accidentally set

pingtoo · Posted: Sat Jul 06, 2024 12:21 pm Post subject:

nameiwillforget,

My test show a different error for dev-perl/Net-SSLeay,

pingtoo · Posted: Sat Jul 06, 2024 1:09 pm Post subject:

Never mind about my comment for the

pingtoo · Posted: Sat Jul 06, 2024 2:50 pm Post subject:

Finish re-sync portage ebuild tree and re-execute riscv64-linux-musl-emerge ... dev-perl/Net-SSLeay

It completed without error.

(So as of today, July, 06, 2024, dev-perl/Net-SSLeay do supported by crossdev tool. My previous comment were incorrect)

nameiwillforget.

Now we need to find out why in your environment the CFLAGS somehow got altered during perl build. Please note, this is NOT crossdev emerge NOR eclass issue, It is somewhere in the perl build system that pickup unexpected CFLAGS. I verified my build.log as your post, the "OPTIMIZE=..." was same as yours build.log that correct gcc options were set. however in your build.log it show it got extra gcc options "-march=alderlake -mabm -mno-cldemote -mno-kl -mno-sgx -mno-widekl -mshstk ..."

I wonder if those extra gcc options came from your crossdev tool gcc spec.

Or can you tell those extra gcc options defined in your host /etc/portage/make.conf?

pingtoo · Posted: Sat Jul 06, 2024 3:51 pm Post subject:

It turn out I am wrong again :oops:

It is known issue for using crossdev build perl modules, see dev-perl/* and perl-core/* packages are not playing well with crossdev.

The actual code issue is in eclass:perl-module.eclass, the function perl-module_src_configure() call "perl" to run "Makefile.PL". And in the crossdev context, the "perl" is CBUILD host "perl" which in turn search CBUILD/lib[64]/perl5 for Config.pm, the Config.pm have build time configuration recorded, therefor the CBUILD host "perl" will have "ccflags" of CBUILD host CFLAGS that could create a problem, when the host CFLAGS have very specific ARCH cc options.

nameiwillforget,

off my head right now, I don't know of a easy solution. So you will have to wait either the bug got addressed or May be I will come up a workaround, (But NO promiss :-)

nameiwillforget · n00b Joined: 07 May 2024 Posts: 37

Hm. Could I cross-compile the program on my laptop, then copy it to my desktop? The cpus of my laptop and desktop are both amd64 but the laptop has an AMD one, the desktop an Intel one.

pingtoo · Posted: Sun Jul 07, 2024 1:20 pm Post subject:

Hu · Administrator Joined: 06 Mar 2007 Posts: 22684

To deal with the bug that pingtoo cites (and to which I alluded above), you could rebuild the host perl with very generic CFLAGS, such as a bare -O2. That flag should be meaningful on all targets, so having it copied into a Raspberry Pi build will not be an error.

nameiwillforget · n00b Joined: 07 May 2024 Posts: 37

Thanks Hu, that worked! But now the compilation fails with gcc. Here is the info:

nameiwillforget · n00b Joined: 07 May 2024 Posts: 37

pintoo,

I just thought maybe I could compile that one Perl-program on my laptop, then copy it to my desktop and use it to set up the rest of the cross-compilation environment. But re-compiling Perl with generic CFLAGS is better anyway.

pingtoo · Posted: Mon Jul 08, 2024 2:45 pm Post subject:

nameiwillforget,

I doubt you can cross build gcc.

gcc build have several phase, and later phase will run gcc using target binary which unlikely will work on you build host.

One solution is to setup QEMU for your target. However I never try this way before so I don't know it if will work.

As of the gcc build error. it just mean your cross tool gcc does not understand "-std=gnu++26". I am not sure which version of gcc understood that option. You can try to build a gcc with same version as your cross tool gcc. that out to work. (But you will need to resolve the gcc build phase that will run target binary problem first)

You can review Gentoo wiki

For item 2 and 3 may be outdated but the principle still sound, so make sure you understand the item 1 before following item 2 or 3.

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2436

Hu · Administrator Joined: 06 Mar 2007 Posts: 22684

-std=gnu++26 will be valid one day, and will select C++26 mode. That appears to be supported in recent snapshots of gcc-14:

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2436

pingtoo · Posted: Mon Jul 08, 2024 6:13 pm Post subject:

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2436

nameiwillforget · n00b Joined: 07 May 2024 Posts: 37

pingtoo,

I was following the wiki on setting up the cross build environment and modified the /usr/local/bin/chroot-armv6j script to chroot into aarch64, but when I'm inside and try to do the next few steps, I receive the message that locale-gen is not installed and when I'm using gcc-config I get

pingtoo · Posted: Mon Jul 08, 2024 7:12 pm Post subject:

nameiwillforget · n00b Joined: 07 May 2024 Posts: 37

Yes, but I don't know what else I'm supposed to do. I have systemd-binfmt running and I copied user/bin/qemu-aarch64 to /usr/aarch64-unknown-linux-gnu/usr/bin/. Also, I'm chrooted into the system that's going to run the Pi using QEMU and it works fine there.

pingtoo · Posted: Tue Jul 09, 2024 12:01 am Post subject: