glibc_version_header
glibc_version_header copied to clipboard
wheybags
Explain the disadvantages of linking to old glibc versions
After reading the README, I couldn't tell why I shouldn't always link to glibc 2.5 symbols. Is there any downside?
To be honest, I'm not really sure myself, I don't think I've ever personally found that I needed a newer glibc version for soemthing. I guess if you need some fix that broke compatabilty with an older implementation of a function, causing it to be split with symbol versioning, but I don't think 99% of developers will care/notice what version they're using.
On Thu, May 10, 2018 at 2:15 AM, heinrich5991 [email protected] wrote:
After reading the README, I couldn't tell why I shouldn't always link to glibc 2.5 symbols. Is there any downside?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wheybags/glibc_version_header/issues/12, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCums30XdtwLo6lYi5lx87H_CLLB9Kbks5tw4avgaJpZM4T5LY1 .
After reading the README, I couldn't tell why I shouldn't always link to glibc 2.5 symbols. Is there any downside?
I wonder the same thing, too.
Old glibc versions don't have new features. If you want to call a new function like pthread_cond_clockwait then you have to link to the new glibc that provides the definition of that new function. If you bind some symbols like sqrt and memcpy to older versions, that doesn't remove the dependency on the new function which is only present in the new glibc. You just get older (probably slower, maybe buggy) versions of some symbols, but you still depend on the new glibc.
Are security issues fixed as well on old symbols implementations?
I think typically, yes. e.g. for the realpath function, the realpath@GLIBC_2.0 and realpath@@GLIBC_2.3 symbols share the same __realpath implementation, so fixes are done to __realpath and both versioned symbols get the fix. That might not always be true though.
Old glibc versions don't have new features.
Can't we just declare that stuff "feature complete", freeze it indefinitely, and add new functions in other libraries?