This is entirely my fault. 😢

The problem

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.

This is fixed by:

#238154