This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why does pthread_cancel_init() dlopen

On Mon, Oct 19, 2009 at 11:41 AM, Dave Barach <> 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
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

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
* 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
* 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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]