GNU C Library 2.36 Released With New Functions, More Optimizations

[bobbie424242]

- You cannot statically linked with GLIBC

You can if you do not make use of dlopen and NSS functionality.

[rene]

Actually did not bootstrap, needed a showstopper hot fix, but updated now: https://www.youtube.com/watch?v=9L3hAWNdZsk

[NobodyXu]

You can if you do not make use of dlopen and NSS functionality.

You also have to avoid using iconv, as mentioned here, https://stackoverflow.com/questions/...bc-discouraged , which means that you cannot use stdio.

[NobodyXu]

sure you can.

Yes you can in theory, but no in reality.

You'd have to avoid using dlopen, NSS and iconv (locale, used in stdio), as mentioned here, https://stackoverflow.com/questions/...bc-discouraged , which means that you cannot use stdio.h.

it also supports a LOT of functions. Besides, on modern systems most of it is shared by all processes using it, and ram has become plentiful.
Outside of memory-constrained embedded systems this is not an issue, and these tend to use libraries better suited
for their use case (I remember qnx6 allowed to trim the libc of the final image to contain only the functions that were
actually used by any process of that image, saved a few kilobytes).

That one is great, but not always needed.

Most of the time, musl libc is more than enough.

And yet almost everyone outside of embedded uses it, and and noone has stepped up to rectify these differences. They must be doing something right or the incompatibility with posix is not as grave as you think.

I didn't investigate into the improvement of glibc, but I use musl libc where portability is needed, like cargo-binstall https://github.com/ryankurte/cargo-binstall .
With musl libc, I can create a statically linked executable that works on anywhere.

[NobodyXu]

Of course you can statically link with GLIBC. GLIBC is large because it has lots of features and supports lots of targets and many optimizations. But how does its size matter given it is shared across many binaries? I don't see any non-standard behaviour in your link, it's not a bug if you support additional floating point formats or printf specifiers. It's funny you mention MUSL, they seem religiously against optimization - even today many MUSL string functions simply process one byte at a time without any optimization whatsoever. Good luck with that!

Checkout my last reply to mlau for why you cannot statically link with Glibc in practice.

Regarding the optimization, yeah they are not as good as glibc, but that also means their implementation is more robust.
You don't always need that much micro-optimization and often other tools already provide that functionalities.

Since I mostly program in rust, its std library is powerful enough and llvm is already pretty good at optimization.

[Vorpal]

Michael More Typos: "These are4random functions wrap getrandom and /dev/urandom for high quality randomness from the kernel."

[mlau]

Yes you can in theory, but no in reality.

You'd have to avoid using dlopen, NSS and iconv (locale, used in stdio), as mentioned here, https://stackoverflow.com/questions/...bc-discouraged , which means that you cannot use stdio.h.

I can't quite understand why you'd want to statically link the libc but then dlopen() other dependencies.
As to iconv/nss/ I trust you know more about that than me.

I didn't investigate into the improvement of glibc, but I use musl libc where portability is needed

what does "portability" here mean exactly?

[NobodyXu]

I can't quite understand why you'd want to statically link the libc but then dlopen() other dependencies.

Nah, I don't need to dlopen other lib, but stdio.h seems to require iconv according to the link.
I never tried statically linked with Glibc myself because of its notorious fame and on the other hand, linking with musl libc is really easy and generates a small nice binary.

what does "portability" here mean exactly?

You don't have to care about the version of Glibc on your target.

I remember that ubuntu 16/18 changes the Glibc, and anything compiles on these mew ubuntu cannot run on the old ones.

I didn't look into it, but this is sth you need to handle when using dynamic linking.

[sinepgib]

Nah, I don't need to dlopen other lib, but stdio.h seems to require iconv according to the link.
I never tried statically linked with Glibc myself because of its notorious fame and on the other hand, linking with musl libc is really easy and generates a small nice binary.

You don't have to care about the version of Glibc on your target.

I remember that ubuntu 16/18 changes the Glibc, and anything compiles on these mew ubuntu cannot run on the old ones.

Yes, backwards compatibility on glibc is a mess, I had to fight it many times already. That and the graphic toolkits are probably the main reason we ended up with the Flatpak/Snap mess in the first place.
That said, my guess is the value of static linking glibc is that you depend less on the version of glibc in the target, rather than not depending on the libc at all. Less surface for their "oh this symbol is too old" shenanigans.

Regarding the optimization, yeah they are not as good as glibc, but that also means their implementation is more robust.

That's a non-sequitur. Optimizations don't necessarily reduce robustness. They just mean extra work debugging each implementation, but it's a different issue altogether.

And yet almost everyone outside of embedded uses it, and and noone has stepped up to rectify these differences. They must be doing something right or the incompatibility with posix is not as grave as you think.

Who'd have thunk running an embedded device you control means you know you can rely on a particular implementation rather than having to follow POSIX to the letter, right?

[mlau]

You don't have to care about the version of Glibc on your target.

You don't have to with a statically linked glibc either, I think that's one of the point of statically linking.