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.
2012-08-22 Joseph Myers <jos...@codesourcery.com>
* Makefile.in (vis_hide, gen-hide-list): Do not make definitions
depend on --enable-shared.
($(lib1asmfuncs-o)): Use %.vis files independent of
--enable-shared.
* static-object.mk ($(base)$(objext), $(base).vis)
($(base)_s$(objext)): Use same rules for visibility handling as in
shared-object.mk.
(for some architectures, the subsequently added --with-glibc-version is
needed to get the bootstrap compiler correctly configured when it can't
examine glibc headers).
--
Joseph S. Myers
jos...@codesourcery.com
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
