Re: Support installing headers for bootstrapping libgcc

["Joseph S. Myers" <joseph at codesourcery dot 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 
also

/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
joseph@codesourcery.com