xbps-src fails with 'XBPS_CROSS_TRIPLET is not defined' when trying to cross-build same arch

[Anachron]

When accidently trying to cross-compile (for example with automation scripts) from one arch to the same it will error out with a non-descriptive error: XBPS_CROSS_TRIPLET is not defined

I think it would be good to check if both archs are equal and then error out displaying a msg that it's not allowed.

[SirFerdek]

I came here as I've just stumbled upon this interesting issue myself.

I need to confess I did try to cross-compile to the same arch on purpose. I had prior experience with Crosstool-ng and Buildroot toolchains for building embedded linux distributions and I assumed this is normal practice 😱

Let me explain myself - the thing is that cross-compiling from one arch to the same is the foundation of how instance Buildroot was designed. Quoting their manuals:

The system installed on your development station certainly already has a compilation toolchain that you can use to compile an application that runs on your system. If you’re using a PC, your compilation toolchain runs on an x86 processor and generates code for an x86 processor. Under most Linux systems, the compilation toolchain uses the GNU libc (glibc) as the C standard library. This compilation toolchain is called the "host compilation toolchain". The machine on which it is running, and on which you’re working, is called the "host system" [3]. The compilation toolchain is provided by your distribution, and Buildroot has nothing to do with it (other than using it to build a cross-compilation toolchain and other tools that are run on the development host). [...] distribution toolchain is not a "pure" toolchain (i.e. only with the C/C++ library), so we cannot import it properly into the Buildroot build environment. So even if you are building a system for a x86 or x86_64 target, you have to generate a cross-compilation toolchain with Buildroot or crosstool-NG

What this rigor and clear distinction enables is freedom to choose for target:

• standard library implementation and version
• compiler and its version
• binutils version
• minimum supported kernel version for standard library
• detailed configuration of all above
• everything compiled for target is cross-compiled, always; no distinction between normal vs cross- compilation

Once you get spoiled with these, you don't want to give that back...

Anyway, I am clearly missing something about how xbps works and why this is designed and behaves differently. Would anyone mind to explain?

[SirFerdek]

I think what I don't really understand is whether this ./xbps-src -a x86_64 pkg bash ERROR: XBPS_CROSS_TRIPLET is not defined! is a bug or a feature when executed on x86_64-musl system ;)

[Chocimier]

xbps-src is capable of building for x86_64-glibc on x86_64-musl system with

./xbps-src binary-bootstrap -m masterdir-x86_64-glibc x86_64 # once ./xbps-src -m masterdir-x86_64-glibc pkg bash

[SirFerdek]

@xtraeme You might have just snapped me out of my illusions... Just rewording this, so I get it right: While determining if cross-compilation should be used, I need to be worried only about {build,host,target} CPU architecture. Other important things like which compiler at which version I want to use, or which determine execution on target like libc version, are separate matter and cross-compilation is not necessarily needed when these differ.

Is that correct?

If yes, then I know now what was the thing I was missing: In order to have builds which guarantee that no target binaries are linked against host libraries, Buildroot uses toolchains with just C/C++ standard libraries and binutils, with its own "clean, pristine, sysroot" directories (they are called "sysrooted toolchains").

xbps simply uses chroot... <3 ❤️

[Anachron]

@xtraeme @Chocimier At this point I'd just check if both ARCHs are equal and then exit with RC != 0. If that is fine I'll open a PR.

[vincele]

Would it be possible to make it just work ? Would that be expensive (hard to do, maintenance, etc.) ?

[Chocimier]

We do not have such compilers, and there is no benefit of cross-compiling to native architecture as we use chroot.

By now error message is better:

=> ERROR: cross-x86_64-linux-gnu-0.35_3: Can't build crosstoolchain to itself

Closing.