--clear-symbol-version with glibc? #284
Labels
Comments
|
I'm also interested in fixing this bug. Trying to remove version dependency |
|
I think versions are tracked in relocation sections of the binaries i.e. |
|
Did anyone manage to actually do that? |
vszakats
added a commit
to curl/curl-for-win
that referenced
this issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 curl/curl-for-win
that referenced
this issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm trying to monkey patch out a glibc version check, but having a hard time figuring out exactly how the versions are tracked. Haven't been able to figure out how to remove them. Here's what I started with:
Based off this, I cleared the version for
fcntl64@GLIBC_2.28. (At the moment, I'm totally fine if this causes a segfault.)~/Work/patchelf/src/patchelf --debug --clear-symbol-version fcntl64 /home/dave/Work/reven/squashfs-root/usr/lib/libpython3.7m.so.1.0I tried patching the string of
GLIBC_2.28toGLIBC_2.27myself, and oddly enough that did nothing. Same issue.I also tried replacing
libc.so.6as a random last attempt. Didn't seem to make a difference.~/Work/patchelf/src/patchelf --debug --replace-needed libc.so.6 libc.so.6 /home/dave/Work/reven/squashfs-root/usr/lib/libpython3.7m.so.1.0Any ideas on what I'm doing wrong? Not sure if it's something on my end or a limitation of
patchelf.Thanks!
The text was updated successfully, but these errors were encountered: