This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support installing headers for bootstrapping libgcc
On Mon, 14 May 2012, Roland McGrath wrote:
> > * 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?
That would seem to imply setting makefile variables (containing or not
containing -lgcc_eh, etc.) depending on whether it's an early bootstrap
case or not (and so having configure tests for whether it's such a case -
which I'd rather avoid; ideally I think all configure tests would have the
same results whether or not there is a previously built glibc, and seeing
if they do is a good test of whether the work to support bootstrap
properly is complete).
> Certainly we can rework the makefile variables a bit to reduce duplication
> for this.
Advice on appropriate reworking is welcome here.
> > * 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 libc.so 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.
For "generic" architectures, tested x86_64 (more tests will be useful at a
later stage, but I certainly do not expect other generic architectures to
give new issues), I expect problems only for statically linked programs
and tests (mainly tests using unwinding / thread cancellation).
Generic architectures are those using plain DWARF-2 unwind information.
There are two non-generic architectures in this regard in ports, ARM and
IA64; both have their own systems for unwind information. For ARM, the
result is as I described above: undefined references to personality
functions that can always safely be resolved to dummy versions (as long as
you're not linking libgcc_eh into the relevant executable or shared
library - and if you are, it will provide the real implementations). For
IA64, I don't know what issues may arise, and IA64 testing will be
important for later patch revisions.
--
Joseph S. Myers
joseph@codesourcery.com