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 _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc