GNU C Library 2.36 Released With New Functions, More Optimizations

[sinepgib]

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

No, but glibc is somewhat dysfunctional when it comes to static linking, as mentioned (and backed up with links) previously on the thread.

[coder]

Yes you can in theory, but no in reality.

Maybe I missed it, but another reason is the license. LGPL says that if you statically link, then you have to distribute your object files (or source, IIRC) with the executable. This is so that end-users can replace glibc with another version, which either they've modified or perhaps is simply newer and contains security fixes or enhancements needed to better support a newer kernel that they're using.

And this illustrates why it's such a bad idea to statically link libc, in the first place. It's the userspace abstraction over the kernel. You shouldn't want or need to statically link it. If you do, you're probably not even using glibc anyway (maybe something like uclibc, instead).

[coder]

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

Well, maybe don't use glibc features you don't really need, and then just let package management systems (e.g. RPM, DEB) take care of the version dependencies.

I hope anyone distributing binaries is using proper packaging. Otherwise, you deserve what you'll get.

[sinepgib]

And this illustrates why it's such a bad idea to link libc, in the first place. It's the userspace abstraction over the kernel. You shouldn't want or need to statically link it. If you do, you're probably not even using glibc anyway (maybe something like uclibc, instead).

Since the kernel doesn't break userspace but userspace willfully breaks itself, I wouldn't make any universal claims about whether or not static linking is a good or bad idea. In terms of being able to run your program anywhere it doesn't sound bad at all.

[coder]

Since the kernel doesn't break userspace but userspace willfully breaks itself, I wouldn't make any universal claims about whether or not static linking is a good or bad idea. In terms of being able to run your program anywhere it doesn't sound bad at all.

You're ignoring my points about security fixes in glibc and enhancements to better exploit newer hardware and kernel features. It's not as if glibc has a lot of ABI-breaking changes, either (if ever).

If you want your code to be portable, just take care to build it against an old version of glibc, and make sure those version requirements are reflected in your distributable package. I don't know about .deb files, but I know you can accomplish this with RPM's BuildRequires directive. That will ensure it's built against the version you want as your minimum requirement, and your runtime dependency will be automatically deduced from it.

Static linking is a hammer that people often reach for far too readily.

[coder]

linking with musl libc is really easy and generates a small nice binary.

I don't get your point about size. The kernel uses mmap to load shared libraries, with the consequence being that the code segments of shared libraries are loaded only once.

I see two main disadvantages of shared linking:

1. Version management.
2. Symbol relocation overhead, at startup.

We have good solutions to number 1, and number 2 generally hasn't been an issue for a long time, in everyday Linux usage.

[F.Ultra]

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.

You can actually compile with a new version of GLIBC but tell the compiler to use the functions from a older version of GLIBC since GLIBC uses symbol versioning (and one reason why it's so huge is that they keep the older versions of functions around). Now this is not fun to do since you have to specify the version for every single function that you intend to use from GLIBC with something like this:

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

But atleast it's doable.

[coder]

You can actually compile with a new version of GLIBC but tell the compiler to use the functions from a older version of GLIBC since GLIBC uses symbol versioning (and one reason why it's so huge is that they keep the older versions of functions around).
...
But atleast it's doable.

Easier solution is just to build against an older version, if you don't need the capabilities of a newer one. At runtime, you'll still benefit from any optimizations in the version present where your code is being deployed.

As I mentioned, RPM's BuildRequires is an easy way to do it. Then, just use a proper build tool that compiles the RPM in a chroot populated from scratch (like SuSE's build tool, which their cloud-based build service also uses), and you're done.

[PerformanceExpert]

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

In practice it works - I don't use nss/iconv but rely on stdio. GLIBC supports a --with-static-nss config. A while back there was a push to support statically linked PIE binaries. All this suggests static linking is working and actively developed rather than being unsupported/broken/deprecated.

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.

While it contains a lot of old code, GLIBC has far more developers and users testing on lots of different targets. So I don't believe you can conclude anything about robustness.

Various languages are built on top of the C runtime. Since you use Rust, there are many complaints about Rust spending too much time in GLIBC memcpy.

There are certainly ones that reinvent the wheel for no good reason, but if you knew how much effort has been put into GLIBC optimization, you'd understand why I don't have much patience for people who think they can write a better memcpy...

[NobodyXu]

In practice it works - I don't use nss/iconv but rely on stdio. GLIBC supports a --with-static-nss config. A while back there was a push to support statically linked PIE binaries. All this suggests static linking is working and actively developed rather than being unsupported/broken/deprecated.

Check this link https://stackoverflow.com/questions/...bc-discouraged please, users can configure stdio.h to use iconv.

While it contains a lot of old code, GLIBC has far more developers and users testing on lots of different targets. So I don't believe you can conclude anything about robustness.

Various languages are built on top of the C runtime. Since you use Rust, there are many complaints about Rust spending too much time in GLIBC memcpy.

There are certainly ones that reinvent the wheel for no good reason, but if you knew how much effort has been put into GLIBC optimization, you'd understand why I don't have much patience for people who think they can write a better memcpy...

I understood that optimizing is hard and I always appreciate the Glibc dev further optimizing memcpy.

Sure, Glibc is also very robustness, but IMHO musl libc is very simple thus easier to maintain and spot errors.
This is not to downplay the effort of Glibc, just saying that sometimes simple is better than more complex solution and as I have said before on this thread, you don't always need that complexity/performance for your application.

Musl libc already provides enough value in many scenarios so why not use it?
I was not promoting again just of Glibc, just saying that somtimes Musl libc is also a very valid option and a very reasonable and logical one.