Announcement

Collapse
No announcement yet.

Musl 1.1.16 Released, Fixes CVE Integer Overflow, s390x Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Musl 1.1.16 Released, Fixes CVE Integer Overflow, s390x Support

    Phoronix: Musl 1.1.16 Released, Fixes CVE Integer Overflow, s390x Support

    A new version of the musl libc standard library is available for those interested in this lightweight alternative to glibc and others...

    http://www.phoronix.com/scan.php?pag....1.16-Released

  • #2
    Awesome, I wish the profiles with musl were stable on gentoo instead of experimental

    Comment


    • #3
      Why is there so much hate on glibc?

      Comment


      • #4
        Originally posted by cj.wijtmans View Post
        Why is there so much hate on glibc?
        What hate? I don't see any hate. glibc is not suited for embedded devices. In contrast Musl is suited for embedded devices and desktops. It's just an alternative for desktops, but not always the better one. It depends on the use case. In general, glibc has the better performance on desktops.

        Comment


        • #5
          Eta Labs maintains a good comparison of C/POSIX standard library implementations for Linux.

          musl offers some advantages over glibc, depending on your perspective. Some of the highlights from a user perspective might be something like:
          • better performance in many cases
          • cleaner codebase, thus hopefully generating fewer bugs
          • less bloat, resulting in smaller binaries, with more potential for efficient static-linking
          • lack of lazy binding support in dynamic linking, though this could also be viewed as a disadvantage if your application depends on this behavior

          Though which of these one cares about will be heavily dependent on your use case.

          Comment


          • #6
            Originally posted by Steffo View Post

            What hate? I don't see any hate. glibc is not suited for embedded devices. In contrast Musl is suited for embedded devices and desktops. It's just an alternative for desktops, but not always the better one. It depends on the use case. In general, glibc has the better performance on desktops.
            I know that but why isnt musl glibc compatible? They are so strict to standards that they dont implement useful functions that should have been standard in the first place. Also some people like to avoid glibc. So i am jsut wondering.

            Comment


            • #7
              Originally posted by cj.wijtmans View Post

              Also some people like to avoid glibc.
              One point of dislike for me is that glibc is huge. If you build linux from scratch, nothing takes longer to compile than glibc. Everything else being equal, more code means more bugs.

              Unfortunately, it's hard to avoid glibc on a desktop system, since most user programs link against it. It would be a huge amount of work to maintain a desktop distro that used something other than glibc. The weird and obscure bugs would be endless.

              Comment


              • #8
                Originally posted by cj.wijtmans View Post
                ... why isnt musl glibc compatible?
                Surely they are both POSIX-compatible, and that is enough.

                Comment


                • #9
                  Originally posted by ldo17 View Post

                  Surely they are both POSIX-compatible, and that is enough.
                  Glibc effectively has proprietary GNU extensions to the C standard library, so many GNU applications utilize this glibc-specific behavior, making their projects unable to compile on platforms without glibc as the choice.

                  Comment


                  • #10
                    Originally posted by mmstick View Post
                    ... many GNU applications utilize this glibc-specific behavior...
                    So don’t run those GNU applications, stick to ones that work with Linux. That is why we call our platform “Linux” and not “GNU” ...

                    Comment

                    Working...
                    X