Comment 16 for bug 1266492

On Wed, 13 Nov 2013, bugdal at aerifal dot cx wrote:

> Carlos, this is yet another reason why dlopen'ing libgcc_s is simply the wrong
> thing to do, and libgcc_eh should be static-linked into libc. (The other big

Static-linking libgcc_eh into any glibc library is a bad idea because it
complicates bootstrapping: it means glibc built with an initial bootstrap
compiler (which was built without glibc headers available, implying full
EH functionality is not present in libgcc) is not identical to glibc built
with a compiler built using full shared glibc and headers. (It's *also* a
bad idea because new compilers can start using new DWARF unwind opcodes
that an old copy of the unwind code won't understand, causing problems
using new programs with old glibc.)

The answer for libpthread is for it to dlopen libgcc_s when loaded rather
than at pthread_cancel time (or to be made to depend (DT_NEEDED) on
libgcc_s in a way that doesn't require libgcc_s to be available when
libpthread is built). The answer for other cases is to disable the
backtracing by default as discussed in bug 12189 (possibly with an
environment variable, not available in setuid programs, that can reenable
it - in which case glibc would dlopen libgcc_s at startup).