handbook: chroot fails "no such file or directory"

[jpsollie]

I have a crossdev setup in aarch64-unknown-linux-gnu.
Whereas it worked before, currently I can't compile several packages anymore, and python is the most important one here

[NeddySeagoon]

jpsollie,

/usr/aarch64-unknown-linux-gnu/ as set up by crossdev is set up for cross compiling. /usr/aarch64-unknown-linux-gnu/ in the target root.
For cross compiling

[jpsollie]

Those are a lot of things! I'll try to answer them one by one:

[NeddySeagoon]

jpsollie,

[jpsollie]

[NeddySeagoon]

jpsollie,

As long as cross compiling works, you do not need a QEMU chroot.
Cross compiling is much faster than a QEMU chroot as QEMU has to emulate the target CPU at the register level, which is slow.
For some things, its either a native build or a QEMU chroot though.

You do need a QEMU chroot to be able to chroot into the arm64 code, because somehow you need to be able to execute the arm64 code.

Cross compiling will give a lot of errors until you fix your target root profile as the cross compiler is going to use /usr/<target>/etc/potage/* when it builds things, not your build host /etc/potage/*
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[jpsollie]

All of that sounds pretty logical. Should I make a new thread to help with python having --build=x86_64_unknown_linux_gnu in the configure script? or do you have some magic tricks I could try?

*EDIT: filed a bug for it:
https://bugs.gentoo.org/show_bug.cgi?id=880137
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img]

[NeddySeagoon]

jpsollie,

Python can be tricky to cross compile.
From memory, it builds some code then runs as as a part of the build process. That has to run on the host during cross compiling.
It it built arm64 code then tried to run it on the build host, I would probably hear the crash. :)

This is the main drawback with cross compile - packages than need to do that but are not cross build aware.

This next bit might make your head hurt.
If you go the QEMU chroot to build things like this, you can use distcc inside the chroot to use the cross compiler on the build host (outside the chroot) as a helper.
That way gcc runs native on the build host, not emulated by QEMU.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[jpsollie]

[NeddySeagoon]

jpsollie,

distcc only distributes C and C++ compile jobs. Big chunks of the build still run on the embedded device.
Linking may run out of real RAM, so builds fail.

That was one of the things that drove me to play with a QEMU chroot for the Raspberry Pi3.
1 GB RAM is too small to build rust, firefox and friends, even in when the Pi3 was new.

gcc is a PITA to build on low end hardware as it is built three times.
The first time with any random C/C++ builds enough of gcc to build itself.
The second time it rebuilds itself with the compiler built in the first stage. There is only one copy of that, so no distcc.
The third time in builds the C/C++ again with the compiler built in stage2. No distcc again.
The results of those two builds are compared. If they are not identical, the build fails.
When all is well, it continues to build the other language targets.
Most of the build cannot use distcc.

When gcc cross compiles itself, it can't do the three pass build as it can't run the output compiler on the build host.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.