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."
Re:Why the Linux kernel limitation (Score:4, Informative)
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.
Re:Why the Linux kernel limitation (Score:5, Informative)
Re:Why the Linux kernel limitation (Score:5, Informative)
For those of you trying to figure out what he's talking about, here's a list of *at syscalls.
http://linux.die.net/man/2/openat [die.net]
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)
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...
Re:Why the Linux kernel limitation (Score:4, Informative)
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 [wikipedia.org] to add to the GNU family mix. Note on the same page there is an OpenSolaris flavor too.
Re:optimized better than the builtins? (Score:5, Informative)
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.