Re: Support installing headers for bootstrapping libgcc

[Roland McGrath <roland at hack dot frob dot com>]

It's not clear to me exactly what all is wrong with install-headers today.
Can you clarify, i.e. enumerate the different problems?

Just making install-headers install a few more things like bits/syscall.h
and bits/stdio_lim.h is fine.  Off hand I don't really recall why those
can't just be in headers (sysdep_headers) and have their own special rules.

For bits/stdio_lim.h it looks like maybe its just that Makerules doesn't
have a pattern rule for a header in $(common-objpfx).  Maybe just add that?

For bits/syscall.h we have this move-if-change logic.  I don't see why we
need that at all, though surely I've forgotten something.  What bad would
happen if we just put it in sysdep_headers and made $(objpfx)bits/syscall.h
rather than $(objpfx)syscall-list.h be the target of the generation rule?

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.

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?

I think each of these can be addressed with smaller individual changes
committed separately, and I think that would be better.


Thanks,
Roland