This is the mail archive of the
mailing list for the GCC project.
Re: Trying to build cross, complains about missing system header files
- To: charles at pentek dot com
- Subject: Re: Trying to build cross, complains about missing system header files
- From: "Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Date: Sat, 6 Nov 1999 21:46:38 +0100
- CC: gcc at gcc dot gnu dot org
- References: <3820A1F0.FAEC9DC9@pentek.com>
> My system unistd.h file contains prototypes for thinks that don't exist
> on my m68k target. No file system, no way to print, etc. What is the
> usual workaround for situations like this?
> Do I supply the system .h files and stub sources for the functions, or
> is there a more elegant solution for this?
> And where should I put the stub sources, assuming that is the solution
> of choice?
It seems that these functions are primarily used for profiling, in
libgcc2.c. If that's the case, I think you have a number of options:
a) define BLOCK_PROFILER_CODE on your target, and none of the _bb
stuff will be compiled. I think you can leave it empty, or put
empty definitions of the necessary functions in it.
b) define inhibit_libc. I think this is meant for newlib, but it may
well work for your environment.
c) provide stub functions. You only need to have header declarations -
libgcc2 is split into many objects, one per function. So if the
compiler never emits the profiling functions (i.e. you never
compile with -pg), then nobody will miss those functions.
Of course, if you do want to support profiling, you have to provide
means to output the profiling data.
P.S. Perhaps there are other reasons to require unistd in libgcc2. If
there are, don't hesitate to ask again.