Cleanup .gnu.version_r after removing symbol version #394

Mic92 · 2022-08-01T08:16:55Z

Continuation of #374
with some more safety checks.

If --clear-symbol-version is used to remove all occurrances of a symbol version, it nevertheless remains in the .gnu.version_r section as being required by a particular dependency. Instead, after removing symbol versions, loop over the .gnu.version and gnu.version_r tables to find any unused version, and unlink them from the linked-lists in the .gnu.version_r section.

This test removes the __libc_start_main@GLIBC_2.34 symbol, which should be the only GLIBC_2.34 symbol in 'main' when built with recent (i.e., > 2.34) glibc. Because it is the only symbol, the entry in .gnu.version_r should also be removed. Because this is a symbol version test, it's unlikely to work on musl or anything else which doesn't use glibc symbol versions. In these cases (or in the case that __libc_start_main is now at a different version), the test should print a warning, but exit with "0" to report a pass.

gudzpoz · 2022-08-17T18:11:49Z

Hello there! I have been trying out the verneed_fix branch in my own build flow, but there seems to be a bug in that it does not check for the end of the list (where vna_next is zero). Here is a patch that I used to fix that.

diff --git a/src/patchelf.cc b/src/patchelf.cc
index 5ea8259..c91a2f2 100644
--- a/src/patchelf.cc
+++ b/src/patchelf.cc
@@ -1755,8 +1755,13 @@ void ElfFile<ElfFileParamNames>::cleanDependencySymbolVersions()
                     auto next_off = (intptr_t)(vern_aux) + rdi(vern_aux->vna_next) - (intptr_t)(ver_r);
                     wri(ver_r->vn_aux, next_off);
                 } else {
-                    auto next_off = (intptr_t)(vern_aux) + rdi(vern_aux->vna_next) - (intptr_t)(prev);
-                    wri(prev->vna_next, next_off);
+                    auto raw_next = rdi(vern_aux->vna_next);
+                    if (raw_next == 0) {
+                        wri(prev->vna_next, 0);
+                    } else {
+                        auto next_off = (intptr_t)(vern_aux) + raw_next - (intptr_t)(prev);
+                        wri(prev->vna_next, next_off);
+                    }
                 }
                 wri(ver_r->vn_cnt, rdi(ver_r->vn_cnt) - 1);
             } else {

This problem did not improve much in the last 20 years. The `patchelf` trick as v0.18.0 (2023-04) is broken due to: NixOS/patchelf#284 NixOS/patchelf#374 NixOS/patchelf#394 Links: https://github.com/phusion/holy-build-box#problem-introduction https://mesonbuild.com/Creating-Linux-binaries.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html

This problem did not improve much in the last 20 years. The `patchelf` trick as v0.18.0 (2023-04) is broken due to: NixOS/patchelf#284 NixOS/patchelf#374 NixOS/patchelf#394 It also looks like a rather fragile and accidental hack. The only real solution is to somehow install older glibc headers and libs and force-build against them. The force-load it when running `curl -V` after the build. There seems to be no out-of-the box way of doing these on Linux. The common solution is to build on a Linux that is older than everyone else's who wants to run the binaries bulit. This is inconvenient, and forces to use old toolchains, possibly with security and performance consequences. Another is to use a tool like crosstool-ng, that involves building the complete toolchain from scratch and also means to deal with a whole lot of supply chain issues, esp. considering the tendency that such tools often pull sources unverified and/or via cleartext HTTP over the internet. Components are often outdated and use custom patches. Plus resources needed for building these. Or possibly using NixOS could help here? Or deploy with Docker, snap, flatpak, which is another thick layer of complexity on top. Links: https://github.com/phusion/holy-build-box#problem-introduction https://mesonbuild.com/Creating-Linux-binaries.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html arm64: ``` U __libc_start_main@GLIBC_2.34 U fstat64@GLIBC_2.33 U fstat@GLIBC_2.33 U pthread_create@GLIBC_2.34 U pthread_detach@GLIBC_2.34 U pthread_getspecific@GLIBC_2.34 U pthread_join@GLIBC_2.34 U pthread_key_create@GLIBC_2.34 U pthread_key_delete@GLIBC_2.34 U pthread_once@GLIBC_2.34 U pthread_rwlock_destroy@GLIBC_2.34 U pthread_rwlock_init@GLIBC_2.34 U pthread_rwlock_rdlock@GLIBC_2.34 U pthread_rwlock_unlock@GLIBC_2.34 U pthread_rwlock_wrlock@GLIBC_2.34 U pthread_setspecific@GLIBC_2.34 U stat64@GLIBC_2.33 U stat@GLIBC_2.33 ``` amd64: ``` U __explicit_bzero_chk@GLIBC_2.25 U __libc_start_main@GLIBC_2.34 U fcntl64@GLIBC_2.28 U fstat64@GLIBC_2.33 U fstat@GLIBC_2.33 w getentropy@GLIBC_2.25 U getrandom@GLIBC_2.25 U pthread_create@GLIBC_2.34 U pthread_detach@GLIBC_2.34 U pthread_getspecific@GLIBC_2.34 U pthread_join@GLIBC_2.34 U pthread_key_create@GLIBC_2.34 U pthread_key_delete@GLIBC_2.34 U pthread_once@GLIBC_2.34 U pthread_rwlock_destroy@GLIBC_2.34 U pthread_rwlock_init@GLIBC_2.34 U pthread_rwlock_rdlock@GLIBC_2.34 U pthread_rwlock_unlock@GLIBC_2.34 U pthread_rwlock_wrlock@GLIBC_2.34 U pthread_setspecific@GLIBC_2.34 U stat64@GLIBC_2.33 U stat@GLIBC_2.33 ```

This problem did not improve much in the last 20 years. The `patchelf` trick as v0.18.0 (2023-04) is broken due to: NixOS/patchelf#284 NixOS/patchelf#374 NixOS/patchelf#394 It also looks like a rather fragile and accidental hack. The only real solution is to somehow install older glibc headers and libs and force-build against them. The force-load it when running `curl -V` after the build. There seems to be no out-of-the box way of doing these on Linux. The common solution is to build on a Linux that is older than everyone else's who wants to run the binaries bulit. This is inconvenient, and forces to use old toolchains, possibly with security and performance consequences. Another is to use a tool like crosstool-ng, that involves building the complete toolchain from scratch and also means to deal with a whole lot of supply chain issues, esp. considering the tendency that such tools often pull sources unverified and/or via cleartext HTTP over the internet. Components are often outdated and use custom patches. Plus resources needed for building these. Or possibly using NixOS could help here? Or deploy with Docker, snap, flatpak, which is another thick layer of complexity on top. Links: https://github.com/phusion/holy-build-box#problem-introduction https://mesonbuild.com/Creating-Linux-binaries.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility arm64: ``` U __libc_start_main@GLIBC_2.34 U fstat64@GLIBC_2.33 U fstat@GLIBC_2.33 U pthread_create@GLIBC_2.34 U pthread_detach@GLIBC_2.34 U pthread_getspecific@GLIBC_2.34 U pthread_join@GLIBC_2.34 U pthread_key_create@GLIBC_2.34 U pthread_key_delete@GLIBC_2.34 U pthread_once@GLIBC_2.34 U pthread_rwlock_destroy@GLIBC_2.34 U pthread_rwlock_init@GLIBC_2.34 U pthread_rwlock_rdlock@GLIBC_2.34 U pthread_rwlock_unlock@GLIBC_2.34 U pthread_rwlock_wrlock@GLIBC_2.34 U pthread_setspecific@GLIBC_2.34 U stat64@GLIBC_2.33 U stat@GLIBC_2.33 ``` amd64: ``` U __explicit_bzero_chk@GLIBC_2.25 U __libc_start_main@GLIBC_2.34 U fcntl64@GLIBC_2.28 U fstat64@GLIBC_2.33 U fstat@GLIBC_2.33 w getentropy@GLIBC_2.25 U getrandom@GLIBC_2.25 U pthread_create@GLIBC_2.34 U pthread_detach@GLIBC_2.34 U pthread_getspecific@GLIBC_2.34 U pthread_join@GLIBC_2.34 U pthread_key_create@GLIBC_2.34 U pthread_key_delete@GLIBC_2.34 U pthread_once@GLIBC_2.34 U pthread_rwlock_destroy@GLIBC_2.34 U pthread_rwlock_init@GLIBC_2.34 U pthread_rwlock_rdlock@GLIBC_2.34 U pthread_rwlock_unlock@GLIBC_2.34 U pthread_rwlock_wrlock@GLIBC_2.34 U pthread_setspecific@GLIBC_2.34 U stat64@GLIBC_2.33 U stat@GLIBC_2.33 ```

This problem did not improve much in the last 20 years. The `patchelf` trick as v0.18.0 (2023-04) is broken due to: https://github dot com/NixOS/patchelf/issues/284 https://github dot com/NixOS/patchelf/pull/374 https://github dot com/NixOS/patchelf/pull/394 It also looks like a rather fragile and accidental hack. The only real solution is to somehow install older glibc headers and libs and force-build against them. The force-load it when running `curl -V` after the build. There seems to be no out-of-the box way of doing these on Linux. The common solution is to build on a Linux that is older than everyone else's who wants to run the binaries bulit. This is inconvenient, and forces to use old toolchains, possibly with security and performance consequences. Another is to use a tool like crosstool-ng, that involves building the complete toolchain from scratch and also means to deal with a whole lot of supply chain issues, esp. considering the tendency that such tools often pull sources unverified and/or via cleartext HTTP over the internet. Components are often outdated and use custom patches. Plus resources needed for building these. Or possibly using NixOS could help here? Or deploy with Docker, snap, flatpak, which is another thick layer of complexity on top. Links: https://github.com/phusion/holy-build-box#problem-introduction https://mesonbuild.com/Creating-Linux-binaries.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility arm64: ``` U __libc_start_main@GLIBC_2.34 U fstat64@GLIBC_2.33 U fstat@GLIBC_2.33 U pthread_create@GLIBC_2.34 U pthread_detach@GLIBC_2.34 U pthread_getspecific@GLIBC_2.34 U pthread_join@GLIBC_2.34 U pthread_key_create@GLIBC_2.34 U pthread_key_delete@GLIBC_2.34 U pthread_once@GLIBC_2.34 U pthread_rwlock_destroy@GLIBC_2.34 U pthread_rwlock_init@GLIBC_2.34 U pthread_rwlock_rdlock@GLIBC_2.34 U pthread_rwlock_unlock@GLIBC_2.34 U pthread_rwlock_wrlock@GLIBC_2.34 U pthread_setspecific@GLIBC_2.34 U stat64@GLIBC_2.33 U stat@GLIBC_2.33 ``` amd64: ``` U __explicit_bzero_chk@GLIBC_2.25 U __libc_start_main@GLIBC_2.34 U fcntl64@GLIBC_2.28 U fstat64@GLIBC_2.33 U fstat@GLIBC_2.33 w getentropy@GLIBC_2.25 U getrandom@GLIBC_2.25 U pthread_create@GLIBC_2.34 U pthread_detach@GLIBC_2.34 U pthread_getspecific@GLIBC_2.34 U pthread_join@GLIBC_2.34 U pthread_key_create@GLIBC_2.34 U pthread_key_delete@GLIBC_2.34 U pthread_once@GLIBC_2.34 U pthread_rwlock_destroy@GLIBC_2.34 U pthread_rwlock_init@GLIBC_2.34 U pthread_rwlock_rdlock@GLIBC_2.34 U pthread_rwlock_unlock@GLIBC_2.34 U pthread_rwlock_wrlock@GLIBC_2.34 U pthread_setspecific@GLIBC_2.34 U stat64@GLIBC_2.33 U stat@GLIBC_2.33 ```

This problem did not improve much in the last 20 years. The `patchelf` trick as v0.18.0 (2023-04) is broken due to: NixOS/patchelf#284 NixOS/patchelf#374 NixOS/patchelf#394 It also looks like a rather fragile and accidental hack. The only real solution is to somehow install older glibc headers and libs and force-build against them. The force-load it when running `curl -V` after the build. There seems to be no out-of-the box way of doing these on Linux. The common solution is to build on a Linux that is older than everyone else's who wants to run the binaries bulit. This is inconvenient, and forces to use old toolchains, possibly with security and performance consequences. Another is to use a tool like crosstool-ng, that involves building the complete toolchain from scratch and also means to deal with a whole lot of supply chain issues, esp. considering the tendency that such tools often pull sources unverified and/or via cleartext HTTP over the internet. Components are often outdated and use custom patches. Plus resources needed for building these. Or possibly using NixOS could help here? Or deploy with Docker, snap, flatpak, which is another thick layer of complexity on top. Links: https://github.com/phusion/holy-build-box#problem-introduction https://mesonbuild.com/Creating-Linux-binaries.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility arm64: ``` U __libc_start_main@GLIBC_2.34 U fstat64@GLIBC_2.33 U fstat@GLIBC_2.33 U pthread_create@GLIBC_2.34 U pthread_detach@GLIBC_2.34 U pthread_getspecific@GLIBC_2.34 U pthread_join@GLIBC_2.34 U pthread_key_create@GLIBC_2.34 U pthread_key_delete@GLIBC_2.34 U pthread_once@GLIBC_2.34 U pthread_rwlock_destroy@GLIBC_2.34 U pthread_rwlock_init@GLIBC_2.34 U pthread_rwlock_rdlock@GLIBC_2.34 U pthread_rwlock_unlock@GLIBC_2.34 U pthread_rwlock_wrlock@GLIBC_2.34 U pthread_setspecific@GLIBC_2.34 U stat64@GLIBC_2.33 U stat@GLIBC_2.33 ``` amd64: ``` U __explicit_bzero_chk@GLIBC_2.25 U __libc_start_main@GLIBC_2.34 U fcntl64@GLIBC_2.28 U fstat64@GLIBC_2.33 U fstat@GLIBC_2.33 w getentropy@GLIBC_2.25 U getrandom@GLIBC_2.25 U pthread_create@GLIBC_2.34 U pthread_detach@GLIBC_2.34 U pthread_getspecific@GLIBC_2.34 U pthread_join@GLIBC_2.34 U pthread_key_create@GLIBC_2.34 U pthread_key_delete@GLIBC_2.34 U pthread_once@GLIBC_2.34 U pthread_rwlock_destroy@GLIBC_2.34 U pthread_rwlock_init@GLIBC_2.34 U pthread_rwlock_rdlock@GLIBC_2.34 U pthread_rwlock_unlock@GLIBC_2.34 U pthread_rwlock_wrlock@GLIBC_2.34 U pthread_setspecific@GLIBC_2.34 U stat64@GLIBC_2.33 U stat@GLIBC_2.33 ```

boicotinho · 2023-12-20T14:24:04Z

Hi, it seems this still not fully working.

I tried this branch just now and removed all version information from symbols which wanted the newer glibc (2.36 in my case) but I still get the error version GLIBC_2.36' not found when ldd`'ing on Ubuntu 22 (glibc 2.35)

sulix and others added 3 commits July 30, 2022 21:11

add more explicit pointer checks when clearing .gnu.version

e1aa6d6

Miepee mentioned this pull request Sep 17, 2022

--remove-needed does not update .gnu.version_r table #214

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cleanup .gnu.version_r after removing symbol version #394

Cleanup .gnu.version_r after removing symbol version #394

Mic92 commented Aug 1, 2022

gudzpoz commented Aug 17, 2022

boicotinho commented Dec 20, 2023

Cleanup .gnu.version_r after removing symbol version #394

Are you sure you want to change the base?

Cleanup .gnu.version_r after removing symbol version #394

Conversation

Mic92 commented Aug 1, 2022

gudzpoz commented Aug 17, 2022

boicotinho commented Dec 20, 2023