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.
The reason given by the commit log is that in -O0, certain functions
end up calling
On 30 September 2014 16:17:35 CEST, Thomas Petazzoni
thomas.petazz...@free-electrons.com 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.
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
On 09/29/14 13:39, Olivier Blin wrote:
On 09/29/14 18:42, Rich Felker wrote:
On Mon, Sep 29, 2014 at 04:43:32PM +0200, Olivier Blin wrote:
EOPNOTSUPP is not a valid error code for posix_fallocate(), the
implementation should have a fallback when the underlying filesystem
does not support
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
On Tue, Sep 30, 2014 at 05:21:43PM -0400, Anthony G. Basile wrote:
On 09/29/14 13:39, Olivier Blin wrote:
On 09/29/14 18:42, Rich Felker wrote:
On Mon, Sep 29, 2014 at 04:43:32PM +0200, Olivier Blin wrote:
EOPNOTSUPP is not a valid error code for posix_fallocate(), the
implementation should
On Tue, 30 Sep 2014, Rich Felker wrote:
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
