[ben-schaaf]

Mixing compilers is not a problem because they use the same standard ABI. You often need to link against the oldest supported version of a library, or dlsym what you need, but you certainly don't need to compile per-distro. The only big exception I know of is musl.

We've been happily compiling a single executable using ~latest clang for years with very few problems beyond using a symbol that doesn't exist on older distros.

[Arnavion]

>Mixing compilers is not a problem because they use the same standard ABI.

So first, you said:

>>What libraries on Linux don't use the SystemV C ABI on x86?

... even though the conversation was about ARM.

Second, you seem to assume that there could be no other problems other than ABI, even though...

>with very few problems beyond using a symbol that doesn't exist on older distros.

... Oh, I shouldn't even need to explain it, because you're already aware of it. So why are you acting contrarian?

When you use gcc version X then it is allowed to generate calls to libgcc version X. If the distro has libgcc version Y, then either you put libgcc version Y in the sysroot and force gcc version X to use it, which gcc version X is not prepared for, or you let gcc version X link the binary to symbols from libgcc version X, and the binary explodes when running against libgcc version Y on the actual system.

Furthermore, if a distro ships gcc version Y and some distro library version Z, it expects you to compile code that uses distro library version Z with gcc version Y. If there are compiler bugs or library bugs, the distro might have patched one or the other to ensure that they work together. By instead compiling with gcc version X (from a different distro, no less) you're breaking that guarantee and again can have silent miscompilations or other runtime issues.

I'm amazed I even have to argue about such basic knowledge. If you don't believe me, maybe you'll believe OSDev?

https://wiki.osdev.org/Libgcc

>Can I use the Linux libgcc?

>You must use the correct libgcc that came with your cross-compiler. Whatever else libgcc you found likely has a different target, was built with different machine compile options, has dependencies on the standard library, is part of a different compiler revision (your distribution may have patched its gcc, even). It is possible that using a different libgcc will work, but perhaps not reliably.

So congratulations on having YOLO'd with no problems "for years", but doing it properly is much easier for correctness and peace of mind, so excuse me if I don't follow suit.

[ben-schaaf]

> even though the conversation was about ARM.

Apologies, I wanted to be specific which standard is being followed. Nonetheless afaik the ABI is the same for all arm distros.

>> with very few problems beyond using a symbol that doesn't exist on older distros. > ... Oh, I shouldn't even need to explain it, because you're already aware of it.

A missing symbol is a problem regardless of where you're compiling. If you're linking against something that doesn't exist it'll fail; whether that's on your client's machine running an old distro or when you're compiling on that old distro yourself. You could argue it's better to fail early here, but the work in fixing this bug is approximately the same.

> I'm amazed I even have to argue about such basic knowledge. If you don't believe me, maybe you'll believe OSDev?

OSDev is incorrect here. Take it from GNU themselves: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html. Symbols in libgcc are versioned; either your code runs and links against the exact correct version or it fails. If you want to run on old distros with libgccs that don't have newer symbols either use an older gcc, statically link libgcc or use clang.