Thanks for the quick explanation. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Rich Felker > Sent: Wednesday, September 05, 2012 1:13 AM > To: [email protected] > Subject: Re: Static linking and Thread Cancellation > > On Tue, Sep 04, 2012 at 05:03:04PM -0500, Dubey, Abhishek wrote: > > I am working with uclibc 0.9.33.2 and the latest buildroot with gcc > > 4.7.1. I have a simple code that does thread cancellation. This code > > succeeds when you use shared linking, but it fails into a segmentation > > fault when you use static linking. Has anyone else faced this problem > > before. > > Sadly, I think this is a known issue with no easy fix. The NPTL implementation > of cancellation uses C++-style exception handling with > DWARF2 unwinding to implement cancellations, and in order to avoid a link- > time dependency on the libgcc_s (or libgcc_eh in the static case) unwinding > code, it insists on dlopening libgcc_s at runtime when cancellation is used. > Not only does this break static linking; it also makes any program using > cancellation non-robust since the code aborts the whole program if loading > libgcc_s fails (e.g. due to running out of memory or exceeding some transient > resource limit, or just about any random reason). > > If it's possible, I think uClibc should take out the glibc/NPTL hack of > loading > libgcc_s at runtime, and instead introduce a link-time dependency of > libpthread on libgcc_s. Or uClibc could just drop the exception-based > implementation and replace it with a traditional linked-list-based one... > > Rich > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
