4 ms·

I know of one distro that uses muslc [0] vs. glibc and they have a wrapper that allows most build tools to work (mostly) as expected. Are there any other optio

I know of one distro that uses muslc [0] vs. glibc and they have a wrapper that allows most build tools to work (mostly) as expected. Are there any other options? [0] - https://www.musl-libc.org/faq.html https://www.musl-libc.org/faq.html

wyldfire 9y ago
For open source libc? musl, glibc, dietlibc, bionic are the only I know of. The supported targets vary widely among these, though.
- earenndil 9y ago
  There is the freebsd libc; they run their own.
  - rurban 9y ago
    Which is in fact the most used, and arguably technically superior to glibc. freebsd -> darwin, openbsd, netbsd and dragonfly bsd. openbsd and netbsd like to add their own stuff on top of it also. The Open Watcom libc and bionic are also superior. bionic is getting better and better recently. musl is in some parts better, in some parts worse. Same for Embarcadero C++ libc. Worse than glibc are only: the two MS libc's, msvcrt and ulibc (which is getting on par), the wine libc, newlib (arguably with dietlibc the worst), uClibc, minilibc.
    - earenndil 9y ago
      > Worse than glibc are only [lists as many libcs as are better than it] Perhaps glibc isn't that bad...
      - rurban 9y ago
        Oh it is. I've listed more quirks here, from the testsuite I've written for all libc's. https://rurban.github.io/safeclib/doc/safec-3.3/d1/dae/md_doc_libc-overview.html https://rurban.github.io/safeclib/doc/safec-3.3/d1/dae/md_do...
quotemstr 9y ago
Last time I checked, musl didn't support random important things. Consider dlclose: unsupported due to an unfounded (IMHO) assertion that it's not possible to implement such a thing safely. Nevertheless, people _have_ been unloading shared libraries for decades, so musl asserting that it's impossible makes me question musl's other technical decisions.
- im3w1l 9y ago
  There's a lot of not-safe-but-works-99.9%-of-the-time patterns out there that have been used for decades.
  - quotemstr 9y ago
    Unloading shared libraries is safe. If you insist that it's not, even though it actually works in a real, robust, not probabilistic way, all you're going to do is make me question your technical judgement.

wyldfire 9y ago

For open source libc? musl, glibc, dietlibc, bionic are the only I know of. The supported targets vary widely among these, though.

earenndil 9y ago
There is the freebsd libc; they run their own.
- rurban 9y ago
  Which is in fact the most used, and arguably technically superior to glibc. freebsd -> darwin, openbsd, netbsd and dragonfly bsd. openbsd and netbsd like to add their own stuff on top of it also. The Open Watcom libc and bionic are also superior. bionic is getting better and better recently. musl is in some parts better, in some parts worse. Same for Embarcadero C++ libc. Worse than glibc are only: the two MS libc's, msvcrt and ulibc (which is getting on par), the wine libc, newlib (arguably with dietlibc the worst), uClibc, minilibc.
  - earenndil 9y ago
    > Worse than glibc are only [lists as many libcs as are better than it] Perhaps glibc isn't that bad...
    - rurban 9y ago
      Oh it is. I've listed more quirks here, from the testsuite I've written for all libc's. https://rurban.github.io/safeclib/doc/safec-3.3/d1/dae/md_doc_libc-overview.html https://rurban.github.io/safeclib/doc/safec-3.3/d1/dae/md_do...

quotemstr 9y ago

Last time I checked, musl didn't support random important things. Consider dlclose: unsupported due to an unfounded (IMHO) assertion that it's not possible to implement such a thing safely. Nevertheless, people _have_ been unloading shared libraries for decades, so musl asserting that it's impossible makes me question musl's other technical decisions.

im3w1l 9y ago
There's a lot of not-safe-but-works-99.9%-of-the-time patterns out there that have been used for decades.
- quotemstr 9y ago
  Unloading shared libraries is safe. If you insist that it's not, even though it actually works in a real, robust, not probabilistic way, all you're going to do is make me question your technical judgement.