On Wed, 1 Oct 2014, Rich Felker wrote: > 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.
This was fixed (at least to the extent needed to get byte-identical glibc as described with glibc >= 2.17; there were also fixes in glibc 2.17 to support building with such a bootstrap GCC) in GCC 4.8 (with --with-glibc-version added in 4.9 to avoid needing to set gcc_cv_libc_provides_ssp=yes when configuring the first GCC on some architectures). -- Joseph S. Myers [email protected] _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
