Am Montag, 4. Januar 2021, 13:57:37 EET schrieb Thomas Mueller:
> > > That's what I did: I found a 2017 stage3 with a still older glibc and
> > > managed to upgrade to a 2020 gentoo while masking the last glibc
> > > versions. That was tricky because I had to git-checkout intermediate
> > > versions of the portage tree in order to deal with the EAPI changes but
> > > I have a working chroot now. Thanks.
> > 
> > That's the easy way to do it, yes.
> > 
> > The hard way is to treat this as a cross-compilation problem and bootstrap
> > your own stages from scratch. Instructions would be a bit longer...
> > 
> > Andreas K. Hüttel
> 
> I have looked through crossdev.  Is that what it would take to cross-compile
> and bootstrap stages from scratch?
> 
> Could that be done from (instead of an old glibc) musl, uClibc, or FreeBSD
> or NetBSD?

In principle yes, but every experimental piece can add more problems. 
It's probably best to start with a base that is as boring as possible.

What crossdev does is (simplified)
* "create" (as symlinks) ebuilds for cross-compiler, cross-binutils, and 
target glibc
* build cross-compiler, cross-binutils, and target glibc
* installs a wrapper for emerge that uses these

For example, you end up on an amd64 system with an additional directory /usr/
riscv64-unknown-linux-gnu that contains 
* a gcc that runs on amd64 (CBUILD) but generates code for riscv64 (CTARGET)
* a binutils that runs on amd64 but works with files for riscv64
* a glibc for riscv64

Then, using commands like
riscv64-unknown-linux-gnu-emerge -av @system
you can build in /usr/riscv64-unknown-linux-gnu pieces of the target system. 

This works only in a very limited way, since many upstream build systems do 
not support cross-compiling. However, with some patience you can get to the 
point where the directory can be tarred up and used as a chroot on the target 
architecture.



-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)