Announcement

Collapse
No announcement yet.

GNU C Library 2.16 Brings Many Features (GLIBC)

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

  • GNU C Library 2.16 Brings Many Features (GLIBC)

    Phoronix: GNU C Library 2.16 Brings Many Features (GLIBC)

    Version 2.16 of glibc, the GNU C Library, was released on Saturday afternoon. This update to the de facto C library for GNU/Linux systems brings many new features. There's x32 and ISO C11 support along with performance optimizations...

    http://www.phoronix.com/vr.php?view=MTEzMDg

  • #2
    Ubuntu uses eglibc instead, so I wonder when these features make it into eglibc..

    Comment


    • #3
      Originally posted by mark45 View Post
      Ubuntu uses eglibc instead, so I wonder when these features make it into eglibc..
      eglibc tries to stay pretty close to glibc so it should not take long.

      personally, I am now more curious about alternative libc-based distros. Musl libc seems to be moving along nicely and I think there is a gentoo variant based on uClibc.

      Comment


      • #4
        Originally posted by staalmannen View Post
        personally, I am now more curious about alternative libc-based distros. Musl libc seems to be moving along nicely and I think there is a gentoo variant based on uClibc.
        Thanks, I've used other libc's before but I hadn't heard of musl.

        Comment


        • #5
          Originally posted by staalmannen View Post
          I am now more curious about alternative libc-based distros. Musl libc seems to be moving along nicely and I think there is a gentoo variant based on uClibc.
          Do you have any insight on the respective strengths of these c libs (other than most likely being smaller and having less baggage) ? It's always been a bit of a jungle for me thus resulting in me staying on the beaten path, maybe I'm missing out on something.

          Comment


          • #6
            Originally posted by XorEaxEax View Post
            Do you have any insight on the respective strengths of these c libs (other than most likely being smaller and having less baggage) ? It's always been a bit of a jungle for me thus resulting in me staying on the beaten path, maybe I'm missing out on something.
            There is a comparison (with potential bias) table at:

            http://www.etalabs.net/compare_libcs.html

            For static linking, I think musl libc got lots of good things going for it. Especially that it is permissively licensed while still being far more complete than the Android bionic libc, so one does not have to worry about license conflicts in static binaries.
            For the base system, having static linking is pretty good (that is how the musl libc "sabotage linux" does it).

            Comment


            • #7
              Thanks for the info!

              Comment


              • #8
                Originally posted by mark45 View Post
                Ubuntu uses eglibc instead, so I wonder when these features make it into eglibc..
                I think that with glibc having adopted its new "development model", the need for the eglibc fork itself is going away.

                Comment


                • #9
                  A(nother?) musl user here...
                  Most alternate libc versions are smaller/lighter than glibc.
                  musl right now (0.9.2) has partial LSB ABI support, which is a subset of glibc ABI. Most other alternate libcs don't have an officially stable ABI.
                  Most users build musl with gcc, but I'm aware of folks using pcc, tcc, and Clang; in fact, ellcc is currently migrating from "libecc" (based on netbsd libc) to musl, and I heard from Rich Pennigton (a week or two ago, on #musl) that a musl-based release should happen in a month or so.
                  Not sure how close to the timeline it will happen, but it "should be soon".

                  There's also a musl Gentoo port/overlay that's been started (mentioned on the musl mailinglist), though AFAICT it may not be usable or public yet.

                  Comment


                  • #10
                    Another release without cortex-strings integrated. Seriously Ubuntu?


                    Re musl - it does cut the bloat, but it also cuts any performance optimizations (no ASM in musl, IIRC) as well as many used functions and behaviors that aren't quite standard, but are supported by glibc and used in the real world.

                    Comment


                    • #11
                      Originally posted by peppepz View Post
                      I think that with glibc having adopted its new "development model", the need for the eglibc fork itself is going away.
                      From what I understand, Ulrich Drepper was perhaps the big reason for the fork, and now that he's gone maybe there's a big kumbaya happening

                      That said, despite what seems like a very hard person to work with I don't think one can doubt his technical ability. His 'what every programmer should know about memory' is the best source of information I've read on the subject.

                      Originally posted by Ibidem View Post
                      A(nother?) musl user here...
                      Most alternate libc versions are smaller/lighter than glibc.
                      musl right now (0.9.2) has partial LSB ABI support, which is a subset of glibc ABI.
                      Thanks for the info, are there any other features you'd like to hightlight outside the realm of small memory footprint? (although small memory footprint certainly is a great feature, particularly since my interest stems from stuff I'm thinking of doing with my Raspberry Pi)

                      Comment


                      • #12
                        I just managed to get php to build on my musl system:

                        https://github.com/staalmannen/sabot...4935eb91c6f9d0

                        Next up should be to try to get the phoronix test suite running.

                        An issue that I still have is chainloading from my syslinux on my Arch root partition (/dev/sda1) to my "sabotage linux" partition (/dev/sda4). Somehow it does not get it and the syslinux info is not that informative unfortunately. The system does however run nicely in a chroot so some preliminary tests of musl libc with pts could probably be done already but ideally I should run a clean system without overhead from a host system.

                        Comment


                        • #13
                          Originally posted by XorEaxEax View Post
                          Thanks for the info, are there any other features you'd like to hightlight outside the realm of small memory footprint? (although small memory footprint certainly is a great feature, particularly since my interest stems from stuff I'm thinking of doing with my Raspberry Pi)
                          small memory footprint is one thing. I think strict POSIX compliance is another.

                          I do believe that this library might replace bionic in Android in the future.

                          When I got time, I will try to get phoronix test suite running on my sabotage install (which now boots) since I now got php properly ported.
                          It may well be that this library also is faster on some operations, which the comparison table seems to indicate. This is still up for testing though.

                          Comment


                          • #14
                            The comparison table was run on an Atom - in-order cpu with hardly any applicable optimizations (probably sse2 or sse3 at most). It'll be interesting to read benches on more reasonable cpus when you get them out

                            Also, as mentioned, strict POSIX compliance is a drawback too, depending on your conditions.

                            Comment


                            • #15
                              Originally posted by curaga View Post
                              The comparison table was run on an Atom - in-order cpu with hardly any applicable optimizations (probably sse2 or sse3 at most). It'll be interesting to read benches on more reasonable cpus when you get them out

                              Also, as mentioned, strict POSIX compliance is a drawback too, depending on your conditions.
                              For anyone willing to bootstrap a "Sabotage linux" system, I have now also packaged phoronix test suite:
                              https://github.com/staalmannen/sabot...32a41a9a25d9b8

                              I still have not had time to play with it and I am also a bit unsure about what types of tests that would be informativ with regards to libc performance. I guess quite many since it is a major communication layer between userland and kernel.

                              Comment

                              Working...
                              X