Currently all crossdev documentation focuses about building stage 3/4 from scratch. However it's a very common scenario to use an existing Gentoo system as the target (without changing the CHOST). The following are the use cases -- 1) An existing Gentoo install needs to be copied to another machine with a different CPU (same CHOST) and hardware configuration (therefore different hardware related CFLAGS. 2) Maintenance of a gentoo installation (in TARGET) using crossdev -- This is a subset of the above. After installation of the TARGET on the desired hardware, the TARGET will be used on the desired hardware; in the process some changes will be made. For an upgrade, a copy of the gentoo installation in the desired hardware will be copied back to /usr/TARGET, upgraded and synced back to the desired hardware. Practical applications -- 1) Maintenance of a laptop Gentoo installations on servers/desktops where both servers/desktop and laptop has different hardware 2) Maintenance of Gentoo in a production server (where you cannot afford to compile packages) and where there is a different build host with a different hardware. CHOST remains the same. In all application -march=native is used (For TARGET -march=native output of the desired hardware is taken and placed within make.conf of the TARGET). I've attempted to do this and it results in the following roadblocks -- 1) glibc and linux-headers conflict with the existing Gentoo installations. 2) With an existing /usr/<TARGET> in place, crossdev fails to build gcc stage 2. These issues where resolved after building the complete -s4 toolchain with a non existent /usr/<TARGET>. Then the existing Gentoo installation was copied to /usr/<TARGET>. With these, 99% of the packages got built. Those 1% which had problems, an attempt was made to rebuild cross-glibc and cross-linux-headers and still building the 1% failed suggesting that replacing cross-glibc and cross-linux-headers with the target's copy has no implications.
> 1) glibc and linux-headers conflict with the existing Gentoo installations. Please include some output for this. They always "conflict" but with _orphaned_ files on the crossdev setup. That might fail with FEATURES=collision-protect (non-default), unlike FEATURES=protect-owned.
I also don't really get yet how ROOT isn't actually sufficient here. The "copying libraries" thing needs more detail too.
Take a look at https://github.com/chewi/cross-boss. It might help you a little. Note that the way we handle the --sysroot flag is about to change, but some keywording needs to happen first.
(In reply to Sam James from comment #1) > > 1) glibc and linux-headers conflict with the existing Gentoo installations. > > Please include some output for this. They always "conflict" but with > _orphaned_ files on the crossdev setup. That might fail with > FEATURES=collision-protect (non-default), unlike FEATURES=protect-owned. I got warning for both glibc and linux-headers about the conflict. They where merged because collision-protect was unset. This is with an existing Gentoo installation copied to /usr/<TARGET>. equery belongs /usr/x86_64-myW-linux-gnu/usr/bin/ld.so * Searching for /usr/x86_64-myW-linux-gnu/usr/bin/ld.so ... cross-x86_64-myW-linux-gnu/glibc-2.39-r6 (/usr/x86_64-myW-linux-gnu/usr/bin/ld.so -> ../../lib64/ld-linux-x86-64.so.2) equery belongs /usr/bin/ld.so * Searching for /usr/bin/ld.so ... sys-libs/glibc-2.39-r6 (/usr/bin/ld.so -> ../../lib64/ld-linux-x86-64.so.2) The machine with sys-libs/glibc-2.39-r6 was copied to /usr/<TARGET>; as a result the library already existed.
(In reply to Sam James from comment #2) > I also don't really get yet how ROOT isn't actually sufficient here. > > The "copying libraries" thing needs more detail too. Because of static libraries. With ROOT=, many builds extract objects from *.a from the host machine and include it in the resultant binary which was built for ROOT. Unfortunately *.a on the host machine is built with -march=native therefore we end up with incompatible instructions in ROOT. SYSROOT resolves this issue, but using it without crossdev is unsupported (this must be added to the man page). I'm not copying any libraries. I'm copying a whole (and working) Gentoo installation into /usr/<TARGET>.
(In reply to James Le Cuirot from comment #3) > Take a look at https://github.com/chewi/cross-boss. It might help you a > little. Note that the way we handle the --sysroot flag is about to change, > but some keywording needs to happen first. Thanks. I'm having a look.
(In reply to dE from comment #5) > Because of static libraries. With ROOT=, many builds extract objects from > *.a from the host machine and include it in the resultant binary which was > built for ROOT. Unfortunately *.a on the host machine is built with > -march=native therefore we end up with incompatible instructions in ROOT. > SYSROOT resolves this issue, but using it without crossdev is unsupported > (this must be added to the man page). > > I'm not copying any libraries. I'm copying a whole (and working) Gentoo > installation into /usr/<TARGET>. You should only use ROOT without SYSROOT if your target system is almost exactly the same. There's far more that can go wrong here than just static libraries. We have never officially declared that native builds with SYSROOT, or native cross as I tend to call it, are unsupported as we would like it to work. We are just aware of several reasons why it currently doesn't. I do have some ideas, but it's never been a priority for me. When I reworked Gentoo Prefix a little while back, I did look into it and concluded that it was basically impossible for Prefix, but I think there's still some hope for non-Prefix.
(In reply to James Le Cuirot from comment #7) > (In reply to dE from comment #5) > > Because of static libraries. With ROOT=, many builds extract objects from > > *.a from the host machine and include it in the resultant binary which was > > built for ROOT. Unfortunately *.a on the host machine is built with > > -march=native therefore we end up with incompatible instructions in ROOT. > > SYSROOT resolves this issue, but using it without crossdev is unsupported > > (this must be added to the man page). > > > > I'm not copying any libraries. I'm copying a whole (and working) Gentoo > > installation into /usr/<TARGET>. > > You should only use ROOT without SYSROOT if your target system is almost > exactly the same. There's far more that can go wrong here than just static > libraries. > > We have never officially declared that native builds with SYSROOT, or native > cross as I tend to call it, are unsupported as we would like it to work. We > are just aware of several reasons why it currently doesn't. I do have some > ideas, but it's never been a priority for me. When I reworked Gentoo Prefix > a little while back, I did look into it and concluded that it was basically > impossible for Prefix, but I think there's still some hope for non-Prefix. I had filed a lot of bugs with SYSROOT=ROOT but they where closed citing it's unsupported. As a result=crossdev. So I try SYSROOT if crossdev doesn't work. Also the 2 machines, although both amd64 are not compatible with -march=native (AMD, Intel, older, newer etc...). I get segfaults otherwise.
(In reply to dE from comment #8) > I had filed a lot of bugs with SYSROOT=ROOT but they where closed citing > it's unsupported. As a result=crossdev. So I try SYSROOT if crossdev doesn't > work. I am aware. I would have kept one of them open, assuming we didn't already have one to cover this, but filing lots of bug reports against different packages when there was clearly a common theme was unhelpful.
I didn't know it was unsupported (as per the man page). I though it was just some package issue. Regardless, this requested feature of crossdev is therefore desired.
That doesn't show a collision occurring? I was also hoping for a static libs example.
Created attachment 902709 [details] cross-x86_64-myW-linux-gnu/linux-headers-6.6-r1 file collisions. That was a fluke of luck. This came up just in time.
Over time I've realized that after cross compiling, if you ever plan to emerge on the target machine independently, it'll result in things like -- ninja: error: '/home/de/temp/x86_64-myW-linux-gnu/usr/lib64/libz.so', needed by 'lib64/qt6/plugins/assetimporters/libassimp.so', missing and no known rule to make it Therefore you've to rebuild many dependencies again before one can start compiling 'natively' again. This is mostly a issue with QT.
