On Tue, Sep 30, 2014 at 09:57:07PM +0200, Bernhard Reutner-Fischer wrote: > On 30 September 2014 16:17:35 CEST, Thomas Petazzoni > <[email protected]> wrote: > >Hello, > > > >In commit 8d31a6e50db423b89082b64a3250eec1b94a7456 ("buildsys: link > >libgcc_eh if DODEBUG"), Bernhard modified the uClibc build system to > >link uClibc against libgcc_eh.a if DODEBUG is enabled. > > This was a workaround for a failure with lockf() IIRC. Linking libgcc_eh in > is wrong, maybe async unwind tables or no-except would get around the lockf() > linker error, maybe later GCC (> 4.8.1 or some such) with -O0 do not expose > the error in the first place.
I'm a little puzzled: is 8d31a6e50db423b89082b64a3250eec1b94a7456 meant to fix the gcc build issue when using DODEBUG, or the SIGABRT issue reported here: https://bugs.busybox.net/show_bug.cgi?id=5174 ? They seem to be related somehow, but I'm not really certain anymore. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275 seems to imply that the optimizer can remove the EH info, presumably needed for the try/catch to function correctly. That bug remains open, but related PR 51117 was marked fixed back in 2011. This stuff is all a bit over my head, but if there is anything I can do to help test or debug, please let me know. I've tried various gcc and uClibc combinations, so far, they all exhibit the SIGABRT problem when an exception is thrown. The only workaround seems to be to compile with -O0 or to pass -fno-omit-frame-pointer. I do gather that NTPL support in uClibc is still considered experimental, though it does seem to be the default configuration for ARM. I'm a bit surprised that this has not caused more problems in C++ applications. Regards, -Ralph _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
