11 ms·
The usual reason is that if you want a binary that can be used "everywhere", you can't just build on your machine without more thought if you use the glibc beca
by glandium 7y ago
The usual reason is that if you want a binary that can be used "everywhere", you can't just build on your machine without more thought if you use the glibc because chances are you're going to be using symbols that aren't available in older versions of the glibc, making your binary incompatible with many (older) distros. musl is an easy way out of that. Another is to build against an old glibc.
- quotemstr 7y agoThe right way to solve this problem would be to teach the linker to link against the set of glibc symbols that existed as of a particular version number or date. Then you'd just pass a flag (along with a preprocessor macro, so the headers would know to define the right version of the linker symbols) specifying this version target when you built your program. For want of this relatively simple toolchain feature, we have people statically linking entire C libraries. It's a shame. You can do a moral version of the same thing using linker scripts, but nobody bothers with linker scripts.
- glandium 7y agoThe macOS SDK does this better. It is indeed a shame that the glibc doesn't care.