This is the mail archive of the libc-help@sourceware.org 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]

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


Wonder if someone can explain why pthread_cancel_init() dlopens
libgcc_s.so.1? 

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

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. 

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

Thanks... Dave Barach 


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