This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Support installing headers for bootstrapping libgcc

> Stubbing things out for ldconfig and sln works.  I have a prototype patch 
> (below) that passes build and test on x86_64, but there are some problems 
> with it:

Thanks for looking into this.

> * Testcases need linking with the appropriate one of -lgcc_eh and -lgcc_s 
> (the former needed by statically linked tests, the latter needed by 
> various NPTL tests such as tst-cancelx*).  Certainly that seems better 
> than linking them with stub files - tests should be built in a way as 
> similar as possible to normal programs built with an installed glibc and 
> compiler.  But I've needed to duplicate various makefile rules and 
> variables to link tests differently from other programs; is there a better 
> way of doing things?

Hmm.  I wonder if it might be good enough (at least for a first iteration)
just to say that 'make check' won't work in the early bootstrap case.
Can we consider this later?

Certainly we can rework the makefile variables a bit to reduce duplication
for this.

> * On ARM, any nontrivial unwind info involves a reference to the 
> personality routine, and there are ARM-specific personality routines.  sln 
> and ldconfig of course need them - I suppose a sysdeps version of 
> static-stubs would deal with that.  But then zic turns out to need them, 
> because of certain division functions in libgcc being built with unwind 
> info, and nscd needs them because of the unwind info in inline syscalls - 
> and if you build with unwind info by default, which can be useful for 
> backtracing, then a lot more programs need the personality routines and 
> would previously have used libgcc_s.  The stub versions that are linked 
> into will always suffice[*], but what is the right way for the ARM 
> makefiles to say "this extra object should be linked into all (non-test) 
> executables being built by glibc"?

I'm confused.  I thought we only had an issue with statically-linked
programs.  Aside from tests, this is just sln and ldconfig.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]