This is the mail archive of the
mailing list for the glibc project.
Re: Why does pthread_cancel_init() dlopen libgcc_s.so.1?
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Dave Barach <dbarach at verizon dot net>
- Cc: libc-help at sourceware dot org
- Date: Mon, 19 Oct 2009 15:37:44 -0400
- Subject: Re: Why does pthread_cancel_init() dlopen libgcc_s.so.1?
- References: <EA0D5D85659C44BD86B82BC41F5DF557@cisco.com>
On Mon, Oct 19, 2009 at 11:41 AM, Dave Barach <firstname.lastname@example.org> wrote:
> Wonder if someone can explain why pthread_cancel_init() dlopens
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
> 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
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
One procedure might look like this:
* Build minimal C compiler (--disable-shared --disable-threads
* 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).