Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Alternative glibc downgrade method using patchelf #28

Open
mid-kid opened this issue Dec 13, 2020 · 3 comments
Open

Proposal: Alternative glibc downgrade method using patchelf #28

mid-kid opened this issue Dec 13, 2020 · 3 comments

Comments

@mid-kid
Copy link

mid-kid commented Dec 13, 2020

patchelf has recently added a new option, named --clear-symbol-version. This clears the symbol version of the specified symbol, making it load any available version (not sure if newest or oldest) instead.

This could be expanded to simply change the symbol version, to achieve the same effect as these headers do, but on already compiled binaries. That would avoid having to rebuild existing binaries, such as miscellaneous system libraries, and indirectly would solve the libgcc/libstdcxx issue, by linking them statically and fixing the symbol versions. This might be useful to create AppImages on systems with newer glibc versions, as linuxdeploy already uses patchelf to fix the RPATH.

Would this work? Am I missing anything, aside from occasional breakage between glibc versions due to glibc header/macro mismatches?

@matonga
Copy link

matonga commented Nov 5, 2022

I think a better alternative would be a program that can load the executable, patch it on the fly to use the system's older glibc version (for example by intercepting system calls). Aside from hurting performance, it would allow anyone to run any program on older systems.

@probonopd
Copy link

Would this work? Am I missing anything

You'd probably get missing symbols errors from the linker. You'd have to implement noops for those somehow. And that might break features...

@mid-kid
Copy link
Author

mid-kid commented Nov 6, 2022

How would it give any linker errors that wouldn't happen with the headers in this repo already? From what I gather, these headers simply change symbol versions in the binary during the assembly stage, producing symbols with invalid versions if they don't exist in the target glibc version. How's this different from changing it in the compiled binary?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants