6 ms·

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

by nomel 2mo 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?

ranger_danger 2mo ago
musl does not perfectly emulate all aspects of glibc, so trying to use libraries that assume glibc can sometimes lead to problems.
- pg83 2mo ago
  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 2mo ago
    Mostly about precompiled libraries (proprietary software) and libraries and software that use GNU extensions.
  - silisili 2mo ago
    Not anymore, but for -years- it did DNS wrong because of the author being pedantic about an RFC wording.
okanat 2mo ago
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.
- uecker 2mo ago
  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 2mo ago
    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 2mo ago
      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 2mo ago
    For example, the itanium unwind ABI implementation lies between these three entities.
  - duped 2mo ago
    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.
    - 2mo ago
akerl_ 2mo ago
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 2mo ago
  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).
  - account42 2mo ago
    Only on current glibc distributions. Your SoLo-program WILL break on future distributions. This is not a sensible tradeoff.
    - yxhuvud 2mo ago
      Who says it is not a sensible tradeoff? It may be a much better tradeoff than not being able to run it at all.
    - pg83 2mo ago
      Any software WILL break on future distributions, sooner or later.
shevy-java 2mo ago
> Why? Have people managed to break the ancient concept of shared libraries If you break or remove a shared lib here, you may no longer be able to compile something from source. I had that happen in the past before I started to use more statically compiled programs (and busybox too). Assuming everything works as-is via shared libraries at all times, makes little sense for ALL linux systems. For instance, some people upgrade glibc manually. Then you need a working base system to resume compilation. I do that for my customized gobolinux system, so I can use any program version as well as any glibc version (assuming I can still compile the program; many older programs no longer compile).
pjmlp 2mo ago
Because many folks don't understand UNIX systems introduced dynamic linking for several reasons, and they actually only had static linking for almost 20 years, since UNIX was known outside Bell Labs. Additionally many other OSes have had both approaches since their early days, Xerox PARC ones. For some strange reason they assume to know better than all those researchers.
- pg83 2mo ago
  These decisions, and these studies, were made a VERY long time ago. It's completely unclear why the decisions made then are relevant now, and why they can't be challenged.
  - pjmlp 2mo ago
    It is like advocating that we should drop cars and go back to chariots, because wooden wheels don't get flat, while forgetting why they are mostly used for tourists nowadays.

by nomel 2mo ago

ranger_danger 2mo ago

musl does not perfectly emulate all aspects of glibc, so trying to use libraries that assume glibc can sometimes lead to problems.

pg83 2mo ago
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 2mo ago
  Mostly about precompiled libraries (proprietary software) and libraries and software that use GNU extensions.
- silisili 2mo ago
  Not anymore, but for -years- it did DNS wrong because of the author being pedantic about an RFC wording.

okanat 2mo ago

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.

uecker 2mo ago
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 2mo ago
  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 2mo ago
    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 2mo ago
  For example, the itanium unwind ABI implementation lies between these three entities.
- duped 2mo ago
  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.
  - 2mo ago

akerl_ 2mo ago

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 2mo ago
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).
- account42 2mo ago
  Only on current glibc distributions. Your SoLo-program WILL break on future distributions. This is not a sensible tradeoff.
  - yxhuvud 2mo ago
    Who says it is not a sensible tradeoff? It may be a much better tradeoff than not being able to run it at all.
  - pg83 2mo ago
    Any software WILL break on future distributions, sooner or later.

shevy-java 2mo ago

> Why? Have people managed to break the ancient concept of shared libraries If you break or remove a shared lib here, you may no longer be able to compile something from source. I had that happen in the past before I started to use more statically compiled programs (and busybox too). Assuming everything works as-is via shared libraries at all times, makes little sense for ALL linux systems. For instance, some people upgrade glibc manually. Then you need a working base system to resume compilation. I do that for my customized gobolinux system, so I can use any program version as well as any glibc version (assuming I can still compile the program; many older programs no longer compile).

pjmlp 2mo ago

Because many folks don't understand UNIX systems introduced dynamic linking for several reasons, and they actually only had static linking for almost 20 years, since UNIX was known outside Bell Labs. Additionally many other OSes have had both approaches since their early days, Xerox PARC ones. For some strange reason they assume to know better than all those researchers.

pg83 2mo ago
These decisions, and these studies, were made a VERY long time ago. It's completely unclear why the decisions made then are relevant now, and why they can't be challenged.
- pjmlp 2mo ago
  It is like advocating that we should drop cars and go back to chariots, because wooden wheels don't get flat, while forgetting why they are mostly used for tourists nowadays.