This is the mail archive of the
mailing list for the glibc project.
Re: Support installing headers for bootstrapping libgcc
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 11 May 2012 13:53:05 +0000 (UTC)
- Subject: Re: Support installing headers for bootstrapping libgcc
- References: <Pine.LNX.email@example.com><20120309190400.552E82C0A7@topped-with-meat.com><Pine.LNX.firstname.lastname@example.org><20120323000616.32F372C08D@topped-with-meat.com>
On Thu, 22 Mar 2012, Roland McGrath wrote:
> 1. Why do we need libgcc at all just to build glibc?
> By this I mean literally to build it, i.e. not to run anything, tests
> or anything else. (Take as given that anything like rpcgen was or
> localedef is, i.e. where we run just-built programs as part of the
> build, would be avoided somehow as we've discussed separately.)
> I guess some bits of libgcc might be required to link the DSOs
> themselves, depending on the machine. Can we cite what those are?
> I think only the traditional libgcc fodder should really be in that
> category (e.g. __muldi3). Nothing for EH should really be required,
> since we use libgcc_s.so only at runtime via dlopen.
> What else is there?
So, I looked into this: building (not testing) glibc without either
libgcc_s or libgcc_eh being used, because building those involves headers
/ crt*.o files from glibc.
On x86_64 (and I expect other architectures, except maybe IA64 with
complications relating to libunwind, to be similar), the shared libc
builds OK without the present -Wl,--as-needed -lgcc_s $(libunwind)
-Wl,--no-as-needed (after all, that does not currently result in libc.so
getting a dependency on libgcc_s). But building glibc also involves
building the statically linked binaries sln and ldconfig. And static
linking without -lgcc_eh fails with a series of errors of the form
/scratch/jmyers/fsf/glibc/build-nm/libc.a(vfprintf.o): In function `_IO_vfprintf_internal':
/scratch/jmyers/fsf/glibc/glibc/stdio-common/vfprintf.c:2052: undefined reference to `_Unwind_Resume'
/scratch/jmyers/fsf/glibc/build-nm/libc.a(vfprintf.o):(.eh_frame+0x287): undefined reference to `__gcc_personality_v0'
(shared libc gets these from sysdeps/gnu/unwind-resume.c, I think) and
/scratch/jmyers/fsf/glibc/build-nm/libc.a(backtrace.o): In function `backtrace_helper':
/scratch/jmyers/fsf/glibc/glibc/debug/../sysdeps/x86_64/backtrace.c:79: undefined reference to `_Unwind_GetIP'
/scratch/jmyers/fsf/glibc/glibc/debug/../sysdeps/x86_64/backtrace.c:82: undefined reference to `_Unwind_GetCFA'
/scratch/jmyers/fsf/glibc/build-nm/libc.a(backtrace.o): In function `__backtrace':
/scratch/jmyers/fsf/glibc/glibc/debug/../sysdeps/x86_64/backtrace.c:109: undefined reference to `_Unwind_Backtrace'
(I think backtrace is being pulled in via __libc_fatal).
So how should these static linking issues be addressed? By arranging for
the versions of the functions that use dlopen to be used in sln and
ldconfig? By arranging for dummy versions that just abort to be used in
those programs? By having appropriate makefile variables and targets to
build and install glibc without these programs and then later build and
install these programs after libgcc_eh has been built and installed?
Joseph S. Myers