| ▲ | nomel 2 hours ago |
| I don't know much about musl. > GPU: Vulkan and OpenGL drivers are supplied by the host as shared objects, usually built against glibc, and a fully static musl binary cannot normally dlopen() them. Why? Have people managed to break the ancient concept of shared libraries, and this is a fix for that? |
|
| ▲ | okanat 2 hours ago | parent | next [-] |
| Because glibc and GNU set a terrible precedent. On GNU/Linux systems the shared binary interpreter / loader, GCC compiler, the C library and the system C/C++ ABI all depend into each other. You cannot change any of them independently. All shared libraries depend on the specific glibc version to load them into memory to be able to use that specific glibc version as their C library and make calls like dlopen. Shared libraries have always been broken in Linux. Unfortunately many things like GPU drivers, graphics libraries and NSS need shared libraries to dynamically load certain runtimes (because you don't want to load all possible GPU drivers in existence to your RAM). So an ecosystem has been developed on top of terrible ABI and architecture GNU/glibc provided. |
| |
| ▲ | asveikau 2 hours ago | parent | next [-] | | > system C/C++ ABI C++ abi should not be included in this. It is independent from the other pieces and historically a source of incompatibility on its own. Saying "C/C++ abi" as if they are the same is looney tunes, the former is very simple and stable and the latter is very complex. | | | |
| ▲ | uecker 2 hours ago | parent | prev | next [-] | | In what sense do binary interpreter / loader, GCC compiler, C library and system C/C++ ABI dependent on each other? I have certainly mixed different versions of all these components without problems so far. | | |
| ▲ | okanat 2 hours ago | parent | next [-] | | When you compile GCC you need to provide a full glibc installation as your target. It is also a dependency of libstdc++. C++ global/static variable initialization depends on the specific version of glibc (they don't usually break compat, but they can and they did in the past) which also provides ld-linux.so that loads those global variable placeholders in the correct manner such that glibc and libstdc++ can initialize them correctly. This is just one example. Thread local variables and behavior of things like pthreads with signal, fork etc all depend on glibc. | | |
| ▲ | uecker an hour ago | parent [-] | | I can't comment on the C++, I can imagine there plenty of issues, but for C I don't see this. You need some libc if you compile with gcc, but this generally does not introduce a hard version dependency on the specific version (there may be a minimum requirement if you compile against a new version that a symbol with a different ABI). |
| |
| ▲ | pg83 an hour ago | parent | prev | next [-] | | For example, the itanium unwind ABI implementation lies between these three entities. | |
| ▲ | mananaysiempre an hour ago | parent | prev | next [-] | | I don’t imagine that you’re unaware of any of this, but: ld.so and libc.so are heavily interdependent in deliberately undocumented ways with Glibc and outright the same file with shared Musl. And while you might usually get away with using any old GCC with the right architecture and ABI (especially for C; cf the musl-gcc hack), technically it needs to be built to target a specific libc version (particularly via symbol versioning; I’ve long wanted to gather a set of patches to build an old Glibc and subsequently a cross-compiler using a new GCC so I could avoid PyPA’s manylinux monster or its moral equivalent for compatible dynamic binaries in simple cases). The C compiler of course is tied to the C ABI, and this wouldn’t be really worth mentioning except for the time where the GCC devs accidentally the whole SysV i386 ABI and pretended that the stack was always 16-byte aligned, why do you ask, except on RHEL. The C++ parts I can’t really comment on. | | |
| ▲ | uecker an hour ago | parent [-] | | I am not really sure. For ld.so and libc.so I may believe this. The C ABI is very stable, and if you use a new symbol from a newer glibc, you certainly depend on it, but this can also be avoided. In any case, I do not see what is fundamentally misdesigned here. I can't quite image how it could work differently. If you upgrade something so that the e ABI changed you natually need to update other components. Static linking certainly seems a very poor replacement for this. |
| |
| ▲ | duped an hour ago | parent | prev [-] | | 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 an hour 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 36 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. |
|
|
|
|
|
| |
| ▲ | b5n an hour ago | parent | prev | next [-] | | While I don't disagree with some of the pain you describe, you conveniently gloss over the fact that gnu developed a system that worked, and then made it free to everyone to consult and use. | | |
| ▲ | okanat an hour ago | parent [-] | | BSD also did it. They did it better. Maybe more modern but AOSP also did it but at a different level of binary: instead of ELF, using compiled Java bytecode archives. |
| |
| ▲ | duped an hour ago | parent | prev [-] | | > all shared libraries depend on the specific glibc version to load them Not really, though. glibc uses symbol versions that are forward but not backward compatible. If you got an error that said "this program was built for a newer version of <distro>" would you say the same thing? Note this is the same (if not worse) on MacOS, and on windows you used to distribute the CRT with your application just to deal with the same problem. | | |
| ▲ | okanat an hour ago | parent [-] | | See https://news.ycombinator.com/item?id=49355262 . Yes glibc has some backwards compat but you cannot load a binary compiled with a newer version of glibc using an older ld-linux.so. That's because the interdependency. Nor you can load binaries that depend on different libc.so files with glibc systems I cannot comment on macOS, I have never used it. However this is not a problem with Windows. You can ship a newer CRT or you can install it as a system component using Microsoft's MSI. The dependency is one way on Windows. CRT purely depends on Win32. Moreover the loader is completely independent and DLLs are loaded into their own unique scoped namespace unlike Linux that loads them in global symbol namespace. That's why you can mix and match DLLs compiled for different CRT versions. | | |
| ▲ | duped an hour ago | parent [-] | | That's what I'm saying though, glibc-linked binaries are forwards (but not backwards) compatible. | | |
| ▲ | okanat an hour ago | parent [-] | | It is not just compatibility. You cannot load them into the memory with your system dynamic loader. You need to also ship ld-linux.so with the new version of glibc you have, if you were to distribute your program independently. On Windows you don't need to ship a new binary loader. I can just ship Windows 10 UCRT DLL (which is the new libc of Windows) to Vista and my binaries will work. The binary loader isn't interlinked with the libc. |
|
|
|
|
|
| ▲ | akerl_ 2 hours ago | parent | prev | next [-] |
| musl has no problem building and using shared libraries. What you can't do is build something statically with musl and then reliably dlopen shared libraries built with glibc. |
| |
| ▲ | pg83 2 hours ago | parent [-] | | Well, now it's possible! Furthermore, SoLo binaries can run, without modification, on glibc-based distros, alpine, and soon on android/bionic (not committed yet). |
|
|
| ▲ | ranger_danger 2 hours ago | parent | prev [-] |
| musl does not perfectly emulate all aspects of glibc, so trying to use libraries that assume glibc can sometimes lead to problems. |
| |
| ▲ | pg83 2 hours ago | parent [-] | | On the one hand, this is technically true, but on the other, what serious issues do you know that will cause problems in practice? I run tests on 1,000 of the most popular Debian packages. | | |
| ▲ | skydhash 20 minutes ago | parent [-] | | Mostly about precompiled libraries (proprietary software) and libraries and software that use GNU extensions. |
|
|
