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 uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
