You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any binary using our pkgsCross.*.glibc built after #209870 but before #238154 which attempts to use pthread_cancel(3) will (deliberately) segfault.
Since there is no error message and because pthread_cancel(3) is a somewhat-obscure API this is extremely frustrating to troubleshoot.
The reason for the problem
The cross compiler we were using to build glibc between those two commits didn't have a libgcc_s.so. So when glibc attempts to dlopen()libgcc_s.so, it can't find it. The glibc developers believe that segfaulting without an error message is the right thing to do in this situation.
Additional details
Our cross compilers don't (currently) bootstrap using the normal stdenv stages.
The "first stage" gcc (crossStageStatic for cross), doesn't produce a libgcc_s.so since it is a "static only" compiler. This compiler is used to compile glibc. Because libgcc_s.so doesn't exist when glibc is built, pkgsCross.*.glibc.stdenv.cc.cc.libgcc doesn't exist. So user-defined-trusted-dirs isn't added to Makeflags and glibc doesn't know where to look for libgcc_s.so. Also, cross-compiled glibcs won't pull libgcc into their closure like they should.
$ nix-instantiate . -A pkgsCross.aarch64-multiplatform.glibc.passthru.libgcc
error: attribute 'libgcc' in selection path 'pkgsCross.aarch64-multiplatform.glibc.passthru.libgcc' not found
ghost
changed the title
cross compiled binaries cannot find libgcc_s.so
cross compiled binaries segfault on pthread_cancel(3) due to missing libgcc_s.so
Jun 30, 2023
This is entirely my fault. 😢
The problem
Any binary using our
pkgsCross.*.glibc
built after #209870 but before #238154 which attempts to usepthread_cancel(3)
will (deliberately) segfault.Since there is no error message and because
pthread_cancel(3)
is a somewhat-obscure API this is extremely frustrating to troubleshoot.The reason for the problem
The cross compiler we were using to build
glibc
between those two commits didn't have alibgcc_s.so
. So whenglibc
attempts todlopen()
libgcc_s.so
, it can't find it. Theglibc
developers believe that segfaulting without an error message is the right thing to do in this situation.Additional details
Our cross compilers don't (currently) bootstrap using the normal stdenv stages.
The "first stage" gcc (
crossStageStatic
for cross), doesn't produce alibgcc_s.so
since it is a "static only" compiler. This compiler is used to compileglibc
. Becauselibgcc_s.so
doesn't exist whenglibc
is built,pkgsCross.*.glibc.stdenv.cc.cc.libgcc
doesn't exist. Souser-defined-trusted-dirs
isn't added toMakeflags
andglibc
doesn't know where to look forlibgcc_s.so
. Also, cross-compiledglibc
s won't pulllibgcc
into their closure like they should.This is fixed by:
#238154
The text was updated successfully, but these errors were encountered: