inhibit_libc definition patch

[Michael Sokolov]

Geoff Keating <geoffk@cygnus.com> wrote:

> I expect that at some point in the future, trying to build gcc without
> the target system's headers will simply not work.

cgd@sibyte.com (Chris G. Demetriou) responded:

> This is, of course, already the case for the 'add-on' component
> libraries.  However, in my opinion, if the basic GCC + libgcc required
> target headers, that would be very unfortunate.
>
> If you are, for instance, building self-contained ROM firmware or
> operating system kernels, which want libgcc but which have no need for
> the 'normal' system headers or libraries, you're then out of luck.

That's exactly what I was going to say! What if I don't have any headers at
all? I'm using gcc primarily for embedded targets like m68k-coff, m68k-elf, and
similar for other CPUs, where I don't have any kernel, any libc, or anything
else to have "system" headers for. I thought that supporting embedded targets
was one of gcc's requirements...

While we are on the topic of gcc and headers, there are two more things that
are bugging me. Last time I tried building gcc as a native compiler on my
4.3BSD machine (vax-dec-bsd), I got it to build cc1, but then it failed
compiling something with the just-built cc1, presumably for libgcc, complaining
about unistd.h not being found (which 4.3BSD doesn't have). I haven't fully
investigated this yet, and I haven't tested yet whether the same problem will
hit me trying to build a cross-compiler for an embedded target. If it does,
this will be a legit problem with gcc failing on headerless embedded targets
which it is supposed to support. If it this problem doesn't occur when building
a cross-compiler for an embedded target, but does when building a native
compiler on 4.3BSD, this will also be a legit problem with gcc failing on
4.3BSD which it is supposed to support too. But either way there will almost
certainly be a legit problem for me to investigate and fix.

The second thing that bugs me is fixinc'ing. Is there any way to turn it off? I
don't want gcc to fixinc my headers and I agree to take responsibility for any
ANSI C incompatibilities in them. Is there any way I can do it? I.e., just have
gcc look in /usr/include (native) or ${prefix}/target/include (cross) for the
original headers and don't go around copying them into an underground gcc-lib
directory and hacking them there?

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)