Originally posted by mlau
View Post
Announcement
Collapse
No announcement yet.
GNU C Library 2.36 Released With New Functions, More Optimizations
Collapse
X
-
Originally posted by NobodyXu View PostYes you can in theory, but no in reality.
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).Last edited by coder; 02 August 2022, 02:50 PM.
Comment
-
Originally posted by NobodyXu View PostYou don't have to care about the version of Glibc on your target.
I hope anyone distributing binaries is using proper packaging. Otherwise, you deserve what you'll get.
Comment
-
Originally posted by coder View PostAnd 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).
- Likes 2
Comment
-
Originally posted by sinepgib View PostSince 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.
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.Last edited by coder; 02 August 2022, 02:58 PM.
- Likes 2
Comment
-
Originally posted by NobodyXu View Postlinking with musl libc is really easy and generates a small nice binary.
I see two main disadvantages of shared linking:- Version management.
- 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.
- Likes 1
Comment
-
Originally posted by NobodyXu View Post
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.
Code:__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
- Likes 4
Comment
-
Originally posted by F.Ultra View PostYou 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.
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.
- Likes 1
Comment
-
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.
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...
- Likes 1
Comment
-
Originally posted by PerformanceExpert View PostIn 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.
Originally posted by PerformanceExpert View PostWhile 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...
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.Last edited by NobodyXu; 03 August 2022, 11:38 AM.
Comment
Comment