Cleanup .gnu.version_r after removing symbol version#394
Open
Mic92 wants to merge 3 commits into
Open
Conversation
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.
|
Hello there! I have been trying out the 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 { |
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Aug 31, 2023
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
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Aug 31, 2023
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
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Aug 31, 2023
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 ```
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Aug 31, 2023
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 ```
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Aug 31, 2023
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 ```
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Aug 31, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 1, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 3, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 3, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 3, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 4, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 5, 2023
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 ```
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Sep 6, 2023
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 ```
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Sep 6, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 6, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 7, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 7, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 7, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 7, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 20, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 20, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 22, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 22, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 22, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 23, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 23, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 24, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 27, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 28, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 28, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Sep 28, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Oct 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Oct 2, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Oct 3, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Oct 5, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Oct 7, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Oct 7, 2023
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 ```
vszakats
added a commit
to vszakats/curl-for-win
that referenced
this pull request
Oct 7, 2023
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 ```
vszakats
added a commit
to curl/curl-for-win
that referenced
this pull request
Oct 8, 2023
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 ```
|
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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Continuation of #374
with some more safety checks.