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 Fri, 9 Mar 2012, Roland McGrath wrote:
> For gnu/stubs.h I don't like this approach at all. Maybe it just can be
> dealt with on the libgcc side? i.e., libgcc can have a private dummy
> gnu/stubs.h used just for its own building, and use -I/-isystem to ensure
> it's found.
I don't think libgcc is the right place for that sort of detail about what
headers are needed internally by other headers but not installed by glibc;
it's an implementation detail in glibc that this header is built by
examining object files from a complete library build, and it's an
implementation detail that it's included by the other headers that libgcc
uses (though it's a public interface that the other headers *somehow* end
up defining __stub_*). The point of this change is to encapsulate the
knowledge of how to install a working set of headers inside glibc, by
providing a single "make" command to install a working set of headers for
a bootstrap - to make the interface between GCC and glibc here narrower,
cleaner and better defined.
Ideally there might also be targets for other bootstrap pieces, in
particular installing crt*.o and a dummy libc.so for use in building a
shared libgcc.
> For sunrpc, the issue is just that the headers are generated by compiling
> rpcgen and thus everything else so as to run it, right? What would happen
> if you just instead declared the bootstrap case to be an instance of
> cross-compiling, so the existing logic (or fixes to it) for the general
> case of "can't run generator programs" applies?
It's possible those builds will work given a cross rpcgen (i.e. rpcgen
built with the build system's libc, its output doesn't depend on the
target) and so don't need conditioning; I'll test that. In general I want
to replace all the cross-compiling conditionals by ones that do things a
bit differently if cross compiling (e.g. build a generator for the build
system) rather than disabling something, so that you get identical
installed results for both native and cross builds.
(In the case of rpcgen the long-term solution would be for the libtirpc
project to provide both the rpcgen program and support for generating
these headers using it.)
--
Joseph S. Myers
joseph@codesourcery.com