Cross-compiling qemu for aarch64 failed, damaged system

nameiwillforget · n00b Joined: 07 May 2024 Posts: 19

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: 19

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: 22021

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: 19

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: 19

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: 22021

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.