Re: Why does pthread_cancel_init() dlopen libgcc_s.so.1?

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, Oct 19, 2009 at 11:41 AM, Dave Barach <dbarach@verizon.net> wrote:
> Wonder if someone can explain why pthread_cancel_init() dlopens
> libgcc_s.so.1?

Thread cancellation requires unwinding which is implemented by
compiler helper routines.

> At a higher level: why are some bits of the pthread implementation present
> in glibc, while other bits come from libgcc?

The compiler does a lot of work to implement unwinding, primarily for
languages that have exception handling mechanisms. The C Library uses
the compiler unwinding machinery to implement some of the pthread
standard requirements.

> Why would one care? When building a cross toolchain: we configure gcc w/
> --enable-threads=single (so the gcc build doesn't depend on glibc), build
> gcc, build glibc, then reconfigure and rebuild gcc to generate
> libgcc_s.so.1.

Build with --disable-threads --disable-shared --without-headers.

> Is there a better way to solve the interdependency between glibc and
> libgcc_s when building a cross toolchain?

Use a pre-built cross-compiler or one of the standard distribution
build frameworks?

One procedure might look like this:

* Build minimal C compiler (--disable-shared --disable-threads
--without-headers)
* Partial C Library build to install required headers (install-headers
target, build some things by hand for next phase)
* Build C compiler (--enable-languages=c)
* Build full C Library (Links against previous steps libgcc.so.1)
* Build full C compiler (Any languages, links properly against final glibc)

Don't forget to run the testsuite during the full builds to verify
everything is working correctly (including unwinding).

Cheers,
Carlos.