The interpreter/loader is glibc and a key part of bootstrapping an executable built against glibc is loading libc itself before continuing on to load the program. Versioning is a problem when distributing binaries linked against a newer glibc to distros that ship an older one. The C compiler doesn't really care as much.

▲

okanat an hour ago | parent [-]

> The C compiler doesn't really care as much.

Until you define a thread local variable (C11) or use atomics (also C11) or define a global with an initial value. Then it happily generates code that depends on "whatever my target glibc + ld-linux.so needs".

▲

uecker an hour ago | parent [-]

It depends on functions defined in a standardized ABI.

▲

okanat an hour ago | parent [-]

You'd expect that but, no. That's why you cannot load glibc-linked binaries in a Musl distro. Edit: that's why the hacks like the original post is needed, as well.

The ABI is strongly dependent on explicit libc implementation in current Linux systems. There is no libc independent ABI on Linux.

▲

uecker 43 minutes ago | parent [-]

Sorry, can you be more specific. I do not understand what the problem is. If Musl does not implement support for the ABI, this would be a musl problem?

	▲	okanat 34 minutes ago \| parent [-]
		There is no libc independent ABI. ABI doesn't purely mean just calling conventions. When you compile libc, you also get a binary loader ld-linux.so with it. They are not two independent components of a system. Basically all .so files compiled with glibc require the ld-linux.so that's also generated by that glibc (or a later version, if they didn't break the binary compatibility). There are a lot of stuff that's executed by ld-linux.so and glibc that are not explicitly documented but they are absolutely necessary for your program to start and correctly initialize things like global variables or signal handling or loading other dynamic libraries. Some of that functionality sits in ld-linux.so and some of that in glibc. They have circular dependencies to each other. glibc expects ld-linux.so to put things in certain order but ld-linux.so also must load glibc first to have access to certain APIs. They are not part of System V ABI. They are not documented. Musl maybe can implement this but it is simply reverse engineering what glibc did and then playing a game of cat and mouse. There is no independent ABI standard.