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

[Rich Felker]

On Tue, Sep 30, 2014 at 10:52:22PM +0000, Joseph S. Myers wrote:
> 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
> > --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.
> 
> I fixed symbol visibility in --disable-shared libgcc over two years ago, 
> and verified that (stripped) glibc built with such a --disable-shared GCC 
> was byte-identical to the glibc you got after a further bootstrap stage of 
> rebuilding GCC and glibc.

Good to know. Do you know what the first release was with this fixed?
A lot of my experience is with people using pre-C++ or even pre-GPLv3
versions so I'd like to be able to give them accurate information.

Rich