Become a fan of Slashdot on Facebook


Forgot your password?
GNU is Not Unix Open Source Programming News

GNU C Library 2.17 Announced, Includes Support For 64-bit ARM 68

hypnosec writes "A new version of GNU C Library (glibc) has been released and with this new version comes support for the upcoming 64-bit ARM architecture a.k.a. AArch64. Version 2.17 of glibc not only includes support for ARM, it also comes with better support for cross-compilation and testing; optimized versions of memcpy, memset, and memcmp for System z10 and zEnterprise z196; and optimized version of string functions, on top of some quite a few other performance improvements, states the mailing list release announcement. Glibc v 2.17 can be used with a minimum Linux kernel version 2.6.16."
This discussion has been archived. No new comments can be posted.

GNU C Library 2.17 Announced, Includes Support For 64-bit ARM

Comments Filter:
  • by kthreadd ( 1558445 ) on Thursday December 27, 2012 @05:36PM (#42406585)

    I read the mailing list post and they do mention the minimum Linux kernel version needed to work with this C library, but it doesn't say why. I'm curious as to what new features they are using that are not in early 2.6.x kernels. For that matter I'm curious as to whether Hurd works with this C library.

    Because it relies on the kernel API compatible with 2.6.16 and later.

    The Hurd project isn't mentioned anywhere in the mailing list post.

    It's my understanding that the Hurd project uses a customized version of glibc.

  • by broken_chaos ( 1188549 ) on Thursday December 27, 2012 @05:43PM (#42406635)
    Best guess I have is that they removed their implementations of the *at syscalls added in 2.6.16 (since almost no one is using that old a kernel anyway and presumably it made the maintenance easier), and will always directly make use of the kernel versions of those. There were a few other syscalls added in 2.6.16, so it might be related to one of those instead (but the *at ones look most likely to me).
  • by CODiNE ( 27417 ) on Thursday December 27, 2012 @07:20PM (#42407297) Homepage

    For those of you trying to figure out what he's talking about, here's a list of *at syscalls. []

    Notice at the bottom of the page the group of similar file access system calls ending in "at". So for handling files with certain kinds of paths you use openat() instead of open()

    I learned something.

  • Re:Christ... (Score:5, Informative)

    by aztracker1 ( 702135 ) on Thursday December 27, 2012 @08:01PM (#42407519) Homepage

    you spend your time dicking with things that were solved 20 years ago but everyone thinks they need to reinvent and do differently without ever asking why it should be done differently in the first place. Its no more a blessing then any other mental illness, you just don't recognize it.

    Well, wooden wheels were first.. eventually metal with tires... as materials improve, sometimes re-inventing the wheel becomes a good idea...

  • by dreamchaser ( 49529 ) on Thursday December 27, 2012 @08:28PM (#42407669) Homepage Journal

    The mailing list post says it is used '... in GNU systems, and is careful to also say '... most systems running the Linux kernel ...', from which I infer that they're two different things. If GNU systems doesn't mean the Hurd, then what would it mean?

    Besides Linux there is at least one variant of BSD [] to add to the GNU family mix. Note on the same page there is an OpenSolaris flavor too.

  • by paskie ( 539112 ) <pasky.ucw@cz> on Thursday December 27, 2012 @08:31PM (#42407689) Homepage

    It's not so simple for two reasons:

    (i) Builtins are used only when gcc wants to inline their code. This may not always be the case. Their usage may (I think) also depend on the nature of the arguments (e.g., are they constant? is their length known? etc.). And there are other weird cases (passing memcpy() function pointer or whatever). Even if you don't explicitly disable builtins, your program may call these functions.

    (ii) This specific part of the announcement concerns ifunc-related optimizations. This means that the version appropriate (most optimized) for the processor the program is _currently running on_ is chosen at runtime. In x86 world, at runtime (during the first call to the function), a SSE4-enabled function may be chosen over default function if the processor supports SSE4, for example. And you have just a single binary of your program to handle.

"An open mind has but one disadvantage: it collects dirt." -- a saying at RPI