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

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Tue Sep 30 20:39:20 UTC 2014


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.

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.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


More information about the uClibc mailing list