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