10 ms·

The libc situation is pretty unfortunate. You can go with glibc for compatibility, but ideally you don't actually use the upstream version but copy the one from

The libc situation is pretty unfortunate. You can go with glibc for compatibility, but ideally you don't actually use the upstream version but copy the one from Debian that has crucial fixes that most of the world uses that they didn't bother to upstream because for a while there, glibc was maintained by the biggest asshole in all of software engineering. On the other hand you have musl, and we can all appreciate its design goals, but then it is similarly maintained by people that believe they and their work are utterly infallible. Hence why to this date they have not made it possible to detect musl and would rather cite you a POSIX standards meeting from 1980 than fix an incompatibility everyone else handles differently. Just ctrl+F musl on http://landley.net/toybox/ http://landley.net/toybox/ for some insight. The last time I felt like smashing the desk because of musl was when I realized you can't stacktrace a thread in a syscall because they refuse to annotate their 10 lines of assembler doing the syscall with the required CFI directives. They would rather wait for someone to write a 200 line AWK script that does it ([1]) than fix debugging on platforms like arm64. 1: https://github.com/bminor/musl/blob/master/tools/add-cfi.x86_64.awk https://github.com/bminor/musl/blob/master/tools/add-cfi.x86...

bonzini 7y ago
> crucial fixes that most of the world uses that they didn't bother to upstream If you are talking about eglibc, it's been merged back for years.
- stefan_ 7y ago
  The specific anecdote I was thinking of is glibc not reloading resolv.conf automatically, making people think they have no internet connectivity for no good fucking reason for decades now. Debian carries a patch since 2006: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272265 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272265 Why is my Pidgin thinking I'm offline, 2007: https://developer.pidgin.im/ticket/2825 https://developer.pidgin.im/ticket/2825 Firefox 2008: https://bugzilla.mozilla.org/show_bug.cgi?id=214538 https://bugzilla.mozilla.org/show_bug.cgi?id=214538 Chef, 2015: https://github.com/chef/chef/issues/2894 https://github.com/chef/chef/issues/2894 Someone stumbled on this brokenness in Rust in 2017: https://github.com/rust-lang/rust/issues/41570 https://github.com/rust-lang/rust/issues/41570 And then drums Wed Aug 2 19:12:20 2017 glibc 2.26 released with a patch. Maybe programs can rely on this behavior starting in 2027.
  - bonzini 7y ago
    Are there other example than this one that's been fixed almost three years ago?
  - rrss 7y ago
    glibc's use of Intel TSX was also a bit of a tirefire, IMO. It got turned on by default for all locks, broke quite a few of applications (which were using locks wrong, but still), then the instructions ended up being broken in every Intel architecture to date that has ever implemented them [1]. Most of the distros put in some patches to disable the use of TSX, but the 'no-lock-elision' flag provided by glibc didn't actually disable all attempts at lock elision. So the end result is that the glibc in Ubuntu 16.04 tries to use TSX for rwlocks, but not mutexes. Which is unfortunate, because the mechanism to opt-out of the use of TSX in glibc was only implemented for mutexes, but not rwlocks. TSX only ever provided performance benefits in specific use cases, and at some point glibc upstream became sane and turned it all off by default and provided opt-in mechanisms instead. [1]: skylake errata: "Using Intel TSX Instructions May Lead to Unpredictable System Behavior", https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-scalable-spec-update.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
    - saagarjha 7y ago
      TSX is supposed to fall back to an alternative implementation anyways if there's a transactional abort, right? What's the issue with keeping it in?
      - rrss 7y ago
        1. TSX has been broken in varying degrees in every architecture since haswell, and not always in a nice way like "always abort." In various steppings of haswell and early broadwell TSX was in various states of disablement, meaning that sometimes the instructions were advertised (in cpuid etc) to work but had subtle bugs, sometimes were advertised to work but were disabled such that any RTM instruction caused SIGILL, and sometimes correctly advertised to not work. The detection of the state of TSX was sufficiently unreliable that glibc ended up with a blacklist of CPU model numbers that were too problematic to even try using TSX. 2. The pthread implementation of mutex using TSX behaved differently from the prior implementation in cases of misuse. This was deemed acceptable because applications that were impacted were using mutexes illegally, but the result was that a ton of software in all the distros started crashing randomly (IIRC the scenario was a double unlock. pre-TSX glibc didn't complain, post-TSX the program crashed or something). 3. TSX was not generally beneficial. The glibc implementation did something like try using a transaction 3 or 5 times before giving up. The worst-case performance of starting the transaction, going as far into the critical section as possible, aborting, repeat 2x, then finally taking the lock normally is much worse than just taking the lock.
ludocode 7y ago
The inability to detect musl is indeed frustrating. One example of this problem is in detecting C11 thread support. This is a feature of the C library, not the compiler, but it's the compiler that sets C11 feature flags. For threads, you can only detect that they aren't supported by __STDC_NO_THREADS__. But of course since this can't be defined retroactively in old versions of musl, you can't use it to detect C11 thread support in musl. And since you can't detect musl at all, you can't even just assume the version of musl is recent enough and turn it on unconditionally. The musl team seems to advocate guessing at supported features by detecting with test compilation (a.k.a. configure scripts.) They don't believe in depending on specific versions of musl because features can be backported or disabled. Okay fine, but then why not give us explicit means to detect it? Why not just define MUSL_C11_THREADS or something so we can detect it at compile-time instead of during a slow, fuzzy, non-portable configure step? Does anyone know of a workaround for this? Does musl define any kind of feature macro that can be used to detect C11 thread support?
- dooglius 7y ago
  Funny, GCC/glibc had this same problem (except you could work around it by detecting the version).
- api 7y ago
  I've never had a problem with C++ on musl/Alpine. ZeroTier ports fine to that target. In fact we use Alpine/musl images to build static binaries for ancient Linux distributions that lack new enough distro-native compilers.
- tlb 7y ago
  Do you have a real system that uses threads if available, but can also work without them? What does the architecture look like?
  - Hello71 7y ago
    there are other threading options available than C11.
  - 7y ago
skrebbel 7y ago
> Just ctrl+F musl on http://landley.net/toybox/ http://landley.net/toybox/ for some insight. Hahah wow that's some class A entertainment. I feel for you and yours!
mwcampbell 7y ago
I think we should cut the musl developers some slack; they're doing some really thankless work and giving it away.
- jacobush 7y ago
  Hypothetically, polishing turds and giving them away is also thankless work. Not saying musl is, don't know the first thing about it.
  - BiteCode_dev 7y ago
    If it is, it's a turd people ask for.
    - Koshkin 7y ago
      Except that you don't have to do it if you don't want to.
- Koshkin 7y ago
  This is what has always rubbed me the wrong way: (a) if it's given away for free, you do not have a right to complain about its quality, and (b) if you do complain, then why don't you go ahead and contribute. A gift horse, I know, but still...
  - benchaney 7y ago
    If the quality is poor people have the right to say so, regardless of the cost. If the projects existence is causing issues for some people, they have a right to complain, even if it is creating a free benefit for someone else. Why would someone contribute to a project they think is inferior? Basically, I don’t understand your objection.
    - Koshkin 7y ago
      I should have put (a) and (b) in quotes.
jbergstroem 7y ago
Adding alternatives (perhaps not usable now for no one but the interested reader): LLVM decided to start building their own last year: https://llvm.org/docs/Proposals/LLVMLibC.html https://llvm.org/docs/Proposals/LLVMLibC.html
- deleted 7y ago
  [deleted]
- quotemstr 7y ago
  Of course they did.
- antiquark 7y ago
  Looks like llvm-libc is being written in C++. Which is... odd. https://github.com/llvm/llvm-project/tree/master/libc/src/string https://github.com/llvm/llvm-project/tree/master/libc/src/st...
  - jupp0r 7y ago
    Why ist that odd? It makes lots of sense to manage resources via RAII for example. C++ has really good C interop too.
    - antiquark 7y ago
      It forces you to include a C++ compiler in your toolchain, which might not be possible for older systems, etc.
      - jfkebwjsbx 7y ago
        Every system has a C++ compiler nowadays, and if they do not, you have plenty options to compile yourself one.
        kevin_thibedeau 7y ago
        No they don't.
Hendrikto 7y ago
> glibc was maintained by the biggest asshole in all of software engineering You mean Roland? What did he do?
- jacobush 7y ago
  Must refer to Drepper.
- ur-whale 7y ago
  >> glibc was maintained by the biggest asshole in all of software engineering > You mean Roland? What did he do? Ulrich Drepper
  - NanoCoaster 7y ago
    Out of curiosity: What did Drepper do? A quick DDG/Google search didn't turn up anything. EDIT: Actually, searching for "Ulrich Drepper asshole" did turn up some stuff. I'd still be interested, as the stuff I found was rather general.
    - tudelo 7y ago
      This seems that it could be upsetting to some people https://udrepper.livejournal.com/7326.html https://udrepper.livejournal.com/7326.html
      - cryptonector 7y ago
        I'd never seen that one. Wow!!
      - coleifer 7y ago
        Did you bother to read? It's about the combinatorial explosion that happens when you need to support lots of configurations. It's apolitical.
        kstrauser 7y ago
quotemstr 7y ago
That musl refuses to implement dlclose() says it all, really. Musl's sin isn't all that different from old glibc's, really: both forget that the system serves programs, not the other way around. The musl author doesn't believe programs should unload code. Therefore, you're not allowed to do it. Musl also removed access to Linux functionality because the author disagrees with the kernel's design: "linux's sched_* syscalls actually implement the TPS (thread scheduling) functionality, not the PS (process scheduling) functionality which the sched_* functions are supposed to have. omitting support for the PS option (and having the sched_* interfaces fail with ENOSYS rather than omitting them, since some broken software assumes they exist) seems to be the only conforming way to do this on linux." LOL. Do you really want to depend on a libc whose author thinks this way? Who removes functionality that the kernel provides because in his opinion the kernel's design is wrong?
- 0xcde4c3db 7y ago
  > The musl author doesn't believe programs should unload code. Therefore, you're not allowed to do it. Where did you get this? A rationale is given at [1], and it's basically: 1) dlclose() being a no-op is allowed by POSIX. 2) It's common for unloading and reloading libraries to trigger subtle/latent bugs, so making dlclose() a no-op leads to more reliable operation in the common case. 3) Managing thread-local storage in combination with unloading libraries is a complex problem, and arguably requires libc to either weaken error handling or leak memory. This is certainly consistent with an opinionated-standards-lawyer-curmudgeon view of the world, but it seems pretty far from just saying that you're not allowed to do it because you shouldn't. [1] https://wiki.musl-libc.org/functional-differences-from-glibc.html#Unloading-libraries https://wiki.musl-libc.org/functional-differences-from-glibc...
  - quotemstr 7y ago
    Yet the bumblebee flies: other libc implementations successfully implement code unloading and no amount of pointing at the standard will make me okay with musl not implementing code unloading, especially when part of the rationale is that other people write buggy code. It's not the place of libc to break functionality because the author believes other programmers can't use that functionality correctly.
boris 7y ago
> ... maintained by people that believe they and their work are utterly infallible. Hence why to this date they have not made it possible to detect musl ... Yes, and they are every bit as fallible as anyone. Here is an example of a pretty pedestrian bug: https://github.com/build2/build2/issues/50 https://github.com/build2/build2/issues/50 And that's a pity, really, since otherwise it looks like a reasonable implementation. But this dogmatic "we know better" attitude now triggers an allergic reaction.
matheusmoreira 7y ago
> the chrt command is broken when built against musl-libc because that project's maintainer decided he didn't like the system calls it depends on, so he removed them¹ from his libc. This software seems to be using Linux-specific functionality through the C library. Wouldn't it be better to use Linux system calls directly in that case? I think it's weird how Linux has no user space library like the kernel DLLs found in Windows. Everyone assumes the C library is the interface to the kernel, even the Linux kernel manuals. Then people end up being burned when the C library maintainers quote POSIX standards at them or omit new system calls people want. I wrote a liblinux² when I first realized this but it's currently unfinished. Eventually the kernel developers made an amazing nolibc.h file³ for their own tools but it doesn't seem to be used outside the kernel itself. Wish they'd publish it as an official Linux system call library! ¹ https://git.musl-libc.org/cgit/musl/commit/?id=1e21e78bf7a5 https://git.musl-libc.org/cgit/musl/commit/?id=1e21e78bf7a5 ² https://github.com/matheusmoreira/liblinux https://github.com/matheusmoreira/liblinux ³ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/include/nolibc/nolibc.h https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- jcranmer 7y ago
  Most operating systems define a libc ABI (or sometimes, merely API) as the interface to their kernel. Linux is the only OS--at least, the only major OS I'm aware of--that defines its interface boundary to be the system call layer itself.
  - matheusmoreira 7y ago
    I don't understand why they use libc for functionality that's specific to each kernel. A standard C library only makes sense for the POSIX stuff everyone follows. Even then people run into incompatibilities in practice because of implementation-defined or undefined behavior or bugs that have to be maintained. In my opinion, Linux is the only operating system that did it right. The system call binary interface is clearly documented¹ at the processor architecture² level so it can be used from any language. Since everything in user space is replaceable, people could actually get rid of C and rewrite everything in Rust (or anything else) if they wanted to. ¹ http://man7.org/linux/man-pages/man2/syscalls.2.html http://man7.org/linux/man-pages/man2/syscalls.2.html ² http://man7.org/linux/man-pages/man2/syscall.2.html http://man7.org/linux/man-pages/man2/syscall.2.html
nwmcsween 7y ago
The reason you don't want to detect musl is the assumptions will break, say there is some incompatibility of some sort and the issue is brought up to the austin group which then clarifies the behavior which musl changes you now have a never ending number of versions you need to detect.
- naasking 7y ago
  That might justify why you shouldn't detect musl, but it doesn't explain why you shouldn't detect features, a use case the musl devs are apparently also refusing to support.

bonzini 7y ago

> crucial fixes that most of the world uses that they didn't bother to upstream If you are talking about eglibc, it's been merged back for years.

stefan_ 7y ago
The specific anecdote I was thinking of is glibc not reloading resolv.conf automatically, making people think they have no internet connectivity for no good fucking reason for decades now. Debian carries a patch since 2006: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272265 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272265 Why is my Pidgin thinking I'm offline, 2007: https://developer.pidgin.im/ticket/2825 https://developer.pidgin.im/ticket/2825 Firefox 2008: https://bugzilla.mozilla.org/show_bug.cgi?id=214538 https://bugzilla.mozilla.org/show_bug.cgi?id=214538 Chef, 2015: https://github.com/chef/chef/issues/2894 https://github.com/chef/chef/issues/2894 Someone stumbled on this brokenness in Rust in 2017: https://github.com/rust-lang/rust/issues/41570 https://github.com/rust-lang/rust/issues/41570 And then drums Wed Aug 2 19:12:20 2017 glibc 2.26 released with a patch. Maybe programs can rely on this behavior starting in 2027.
- bonzini 7y ago
  Are there other example than this one that's been fixed almost three years ago?
- rrss 7y ago
  glibc's use of Intel TSX was also a bit of a tirefire, IMO. It got turned on by default for all locks, broke quite a few of applications (which were using locks wrong, but still), then the instructions ended up being broken in every Intel architecture to date that has ever implemented them [1]. Most of the distros put in some patches to disable the use of TSX, but the 'no-lock-elision' flag provided by glibc didn't actually disable all attempts at lock elision. So the end result is that the glibc in Ubuntu 16.04 tries to use TSX for rwlocks, but not mutexes. Which is unfortunate, because the mechanism to opt-out of the use of TSX in glibc was only implemented for mutexes, but not rwlocks. TSX only ever provided performance benefits in specific use cases, and at some point glibc upstream became sane and turned it all off by default and provided opt-in mechanisms instead. [1]: skylake errata: "Using Intel TSX Instructions May Lead to Unpredictable System Behavior", https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-scalable-spec-update.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
  - saagarjha 7y ago
    TSX is supposed to fall back to an alternative implementation anyways if there's a transactional abort, right? What's the issue with keeping it in?
    - rrss 7y ago
      1. TSX has been broken in varying degrees in every architecture since haswell, and not always in a nice way like "always abort." In various steppings of haswell and early broadwell TSX was in various states of disablement, meaning that sometimes the instructions were advertised (in cpuid etc) to work but had subtle bugs, sometimes were advertised to work but were disabled such that any RTM instruction caused SIGILL, and sometimes correctly advertised to not work. The detection of the state of TSX was sufficiently unreliable that glibc ended up with a blacklist of CPU model numbers that were too problematic to even try using TSX. 2. The pthread implementation of mutex using TSX behaved differently from the prior implementation in cases of misuse. This was deemed acceptable because applications that were impacted were using mutexes illegally, but the result was that a ton of software in all the distros started crashing randomly (IIRC the scenario was a double unlock. pre-TSX glibc didn't complain, post-TSX the program crashed or something). 3. TSX was not generally beneficial. The glibc implementation did something like try using a transaction 3 or 5 times before giving up. The worst-case performance of starting the transaction, going as far into the critical section as possible, aborting, repeat 2x, then finally taking the lock normally is much worse than just taking the lock.

ludocode 7y ago

The inability to detect musl is indeed frustrating. One example of this problem is in detecting C11 thread support. This is a feature of the C library, not the compiler, but it's the compiler that sets C11 feature flags. For threads, you can only detect that they aren't supported by __STDC_NO_THREADS__. But of course since this can't be defined retroactively in old versions of musl, you can't use it to detect C11 thread support in musl. And since you can't detect musl at all, you can't even just assume the version of musl is recent enough and turn it on unconditionally. The musl team seems to advocate guessing at supported features by detecting with test compilation (a.k.a. configure scripts.) They don't believe in depending on specific versions of musl because features can be backported or disabled. Okay fine, but then why not give us explicit means to detect it? Why not just define MUSL_C11_THREADS or something so we can detect it at compile-time instead of during a slow, fuzzy, non-portable configure step? Does anyone know of a workaround for this? Does musl define any kind of feature macro that can be used to detect C11 thread support?

dooglius 7y ago
Funny, GCC/glibc had this same problem (except you could work around it by detecting the version).
api 7y ago
I've never had a problem with C++ on musl/Alpine. ZeroTier ports fine to that target. In fact we use Alpine/musl images to build static binaries for ancient Linux distributions that lack new enough distro-native compilers.
tlb 7y ago
Do you have a real system that uses threads if available, but can also work without them? What does the architecture look like?
- Hello71 7y ago
  there are other threading options available than C11.
- 7y ago

skrebbel 7y ago

> Just ctrl+F musl on http://landley.net/toybox/ http://landley.net/toybox/ for some insight. Hahah wow that's some class A entertainment. I feel for you and yours!

mwcampbell 7y ago

I think we should cut the musl developers some slack; they're doing some really thankless work and giving it away.

jacobush 7y ago
Hypothetically, polishing turds and giving them away is also thankless work. Not saying musl is, don't know the first thing about it.
- BiteCode_dev 7y ago
  If it is, it's a turd people ask for.
  - Koshkin 7y ago
    Except that you don't have to do it if you don't want to.
Koshkin 7y ago
This is what has always rubbed me the wrong way: (a) if it's given away for free, you do not have a right to complain about its quality, and (b) if you do complain, then why don't you go ahead and contribute. A gift horse, I know, but still...
- benchaney 7y ago
  If the quality is poor people have the right to say so, regardless of the cost. If the projects existence is causing issues for some people, they have a right to complain, even if it is creating a free benefit for someone else. Why would someone contribute to a project they think is inferior? Basically, I don’t understand your objection.
  - Koshkin 7y ago
    I should have put (a) and (b) in quotes.

jbergstroem 7y ago

Adding alternatives (perhaps not usable now for no one but the interested reader): LLVM decided to start building their own last year: https://llvm.org/docs/Proposals/LLVMLibC.html https://llvm.org/docs/Proposals/LLVMLibC.html

deleted 7y ago
[deleted]
quotemstr 7y ago
Of course they did.
antiquark 7y ago
Looks like llvm-libc is being written in C++. Which is... odd. https://github.com/llvm/llvm-project/tree/master/libc/src/string https://github.com/llvm/llvm-project/tree/master/libc/src/st...
- jupp0r 7y ago
  Why ist that odd? It makes lots of sense to manage resources via RAII for example. C++ has really good C interop too.
  - antiquark 7y ago
    It forces you to include a C++ compiler in your toolchain, which might not be possible for older systems, etc.
    - jfkebwjsbx 7y ago
      Every system has a C++ compiler nowadays, and if they do not, you have plenty options to compile yourself one.
      - kevin_thibedeau 7y ago
        No they don't.

Hendrikto 7y ago

> glibc was maintained by the biggest asshole in all of software engineering You mean Roland? What did he do?

jacobush 7y ago
Must refer to Drepper.
ur-whale 7y ago
>> glibc was maintained by the biggest asshole in all of software engineering > You mean Roland? What did he do? Ulrich Drepper
- NanoCoaster 7y ago
  Out of curiosity: What did Drepper do? A quick DDG/Google search didn't turn up anything. EDIT: Actually, searching for "Ulrich Drepper asshole" did turn up some stuff. I'd still be interested, as the stuff I found was rather general.
  - tudelo 7y ago
    This seems that it could be upsetting to some people https://udrepper.livejournal.com/7326.html https://udrepper.livejournal.com/7326.html
    - cryptonector 7y ago
      I'd never seen that one. Wow!!
    - coleifer 7y ago
      Did you bother to read? It's about the combinatorial explosion that happens when you need to support lots of configurations. It's apolitical.
      - kstrauser 7y ago

quotemstr 7y ago

That musl refuses to implement dlclose() says it all, really. Musl's sin isn't all that different from old glibc's, really: both forget that the system serves programs, not the other way around. The musl author doesn't believe programs should unload code. Therefore, you're not allowed to do it. Musl also removed access to Linux functionality because the author disagrees with the kernel's design: "linux's sched_* syscalls actually implement the TPS (thread scheduling) functionality, not the PS (process scheduling) functionality which the sched_* functions are supposed to have. omitting support for the PS option (and having the sched_* interfaces fail with ENOSYS rather than omitting them, since some broken software assumes they exist) seems to be the only conforming way to do this on linux." LOL. Do you really want to depend on a libc whose author thinks this way? Who removes functionality that the kernel provides because in his opinion the kernel's design is wrong?

0xcde4c3db 7y ago
> The musl author doesn't believe programs should unload code. Therefore, you're not allowed to do it. Where did you get this? A rationale is given at [1], and it's basically: 1) dlclose() being a no-op is allowed by POSIX. 2) It's common for unloading and reloading libraries to trigger subtle/latent bugs, so making dlclose() a no-op leads to more reliable operation in the common case. 3) Managing thread-local storage in combination with unloading libraries is a complex problem, and arguably requires libc to either weaken error handling or leak memory. This is certainly consistent with an opinionated-standards-lawyer-curmudgeon view of the world, but it seems pretty far from just saying that you're not allowed to do it because you shouldn't. [1] https://wiki.musl-libc.org/functional-differences-from-glibc.html#Unloading-libraries https://wiki.musl-libc.org/functional-differences-from-glibc...
- quotemstr 7y ago
  Yet the bumblebee flies: other libc implementations successfully implement code unloading and no amount of pointing at the standard will make me okay with musl not implementing code unloading, especially when part of the rationale is that other people write buggy code. It's not the place of libc to break functionality because the author believes other programmers can't use that functionality correctly.

boris 7y ago

> ... maintained by people that believe they and their work are utterly infallible. Hence why to this date they have not made it possible to detect musl ... Yes, and they are every bit as fallible as anyone. Here is an example of a pretty pedestrian bug: https://github.com/build2/build2/issues/50 https://github.com/build2/build2/issues/50 And that's a pity, really, since otherwise it looks like a reasonable implementation. But this dogmatic "we know better" attitude now triggers an allergic reaction.

matheusmoreira 7y ago

> the chrt command is broken when built against musl-libc because that project's maintainer decided he didn't like the system calls it depends on, so he removed them¹ from his libc. This software seems to be using Linux-specific functionality through the C library. Wouldn't it be better to use Linux system calls directly in that case? I think it's weird how Linux has no user space library like the kernel DLLs found in Windows. Everyone assumes the C library is the interface to the kernel, even the Linux kernel manuals. Then people end up being burned when the C library maintainers quote POSIX standards at them or omit new system calls people want. I wrote a liblinux² when I first realized this but it's currently unfinished. Eventually the kernel developers made an amazing nolibc.h file³ for their own tools but it doesn't seem to be used outside the kernel itself. Wish they'd publish it as an official Linux system call library! ¹ https://git.musl-libc.org/cgit/musl/commit/?id=1e21e78bf7a5 https://git.musl-libc.org/cgit/musl/commit/?id=1e21e78bf7a5 ² https://github.com/matheusmoreira/liblinux https://github.com/matheusmoreira/liblinux ³ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/include/nolibc/nolibc.h https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

jcranmer 7y ago
Most operating systems define a libc ABI (or sometimes, merely API) as the interface to their kernel. Linux is the only OS--at least, the only major OS I'm aware of--that defines its interface boundary to be the system call layer itself.
- matheusmoreira 7y ago
  I don't understand why they use libc for functionality that's specific to each kernel. A standard C library only makes sense for the POSIX stuff everyone follows. Even then people run into incompatibilities in practice because of implementation-defined or undefined behavior or bugs that have to be maintained. In my opinion, Linux is the only operating system that did it right. The system call binary interface is clearly documented¹ at the processor architecture² level so it can be used from any language. Since everything in user space is replaceable, people could actually get rid of C and rewrite everything in Rust (or anything else) if they wanted to. ¹ http://man7.org/linux/man-pages/man2/syscalls.2.html http://man7.org/linux/man-pages/man2/syscalls.2.html ² http://man7.org/linux/man-pages/man2/syscall.2.html http://man7.org/linux/man-pages/man2/syscall.2.html

nwmcsween 7y ago

The reason you don't want to detect musl is the assumptions will break, say there is some incompatibility of some sort and the issue is brought up to the austin group which then clarifies the behavior which musl changes you now have a never ending number of versions you need to detect.

naasking 7y ago
That might justify why you shouldn't detect musl, but it doesn't explain why you shouldn't detect features, a use case the musl devs are apparently also refusing to support.