uClibc linking against libgcc_eh.a, the right thing to do?

Rich Felker dalias at libc.org
Tue Sep 30 21:58:35 UTC 2014


On Tue, Sep 30, 2014 at 10:39:20PM +0200, Thomas Petazzoni wrote:
> Dear Bernhard Reutner-Fischer,
> 
> On Tue, 30 Sep 2014 21:57:07 +0200, Bernhard Reutner-Fischer wrote:
> 
> > 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.
> 
> Unfortunately, I have no idea what Unwind_Resume() is, what async
> unwind tables or no-except is, so I would hardly be able to propose a
> proper patch for this. I was merely reporting a build issue.

All of this has to do with call stack unwinding/exception throwing.

> At least, it's good to have a confirmation that linking against
> libgcc_eh is not the right solution. It confirms that the two stage gcc
> build process we use in Buildroot is not at fault.

I'm skeptical of this. If the first gcc is built with
--disable-shared, even plain libgcc.a (without the _eh, needed for
certain math operations) is not suitable for inclusion into libc.so.
The issue is that libgcc.a built this way does not have the right
symbol visibility and creates ABI issues for any shared library it
gets linked into. I can dig up an email thread link with more details
if you're interested.

Rich


More information about the uClibc mailing list