C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 15:43 UTC (Wed) by lambda (subscriber, #40735)
In reply to: C library system-call wrappers, or the lack thereof by Cyberax
Parent article: C library system-call wrappers, or the lack thereof

I have a simple program that uses ages-old epoll/read/print functions. Yet I can't compile it on recent distributions and run on RHEL6. This makes no sense whatsoever.

The problem is not symbol versioning, it's just that the linker always opts to use the latest version of symbols and doesn't give you a way to opt in to a particular compatibility level. If you could opt in to using older symbols when you want to compile on a newer distro and have compatibility with RHEL6, then you could have your cake and eat it too.

That's why it needs to live in a separate daemon.

This is definitely true. NSS as dynamic libraries that get called by your process when it's doing name resolution or calling getent was a terrible idea, and really needs to be replaced.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 15:04 UTC (Thu) by cortana (subscriber, #24596) [Link]

> If you could opt in to using older symbols when you want to compile on a newer distro and have compatibility with RHEL6, then you could have your cake and eat it too.

I think you can do this with the .symver directive?