You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
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?
The text was updated successfully, but these errors were encountered: