GCC-headers, was "Compiling gcc-2.95.2 for use as m68k cross compiler"

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Noah Aklilu wrote:
> 
> It is missing the c library header files.  If you have prebuilt
> libraries and headers, then you can use
> --with-headers=<pathtoheaders> and --with-libs=<pathtolibs> with
> configure.

 These are not recommended, at least by me, when using newlib or
glibc...

 The pointed headers will be copied into '$prefix/$target/sys-include'
and then tried to be fixed --- gcc-2.95.2 and the GCC-snapshots probably
don't do anything, but the earlier GCCs may spoil the originally fully
working headers...

 Copying the target headers into the '$prefix/$target/include', as has
been done for years, and as the GCC-manual instructs in "Installing /
Cross-Compiler" is the safe way...

 If the standard target headers really need fixing, copying them into
the '$prefix/$target/sys-include' or pointing into them using
'--with-headers=....' is the way, the 'cross-make' addition to
'gcc/Makefile' will then pass them to fixinc. The scheme seems to be
that the bug-ridden target headers remain 'as-is' or untouched in the
'$prefix/$target/sys-include' and the by-fixinc fixed GCC-ready headers
will be installed into '$prefix/lib/gcc-lib/$target/$version/include',
into the GCC_INCLUDE_DIR...

 Suggesting to use the '--with-headers=...' says that you think the
newlib headers being full of bugs and the 'fixinc' coming with the
GCC-sources should fix them... My thought is that it is fully possible
to send bug reports to Cygnus regarding the newlib bugs and the headers
will be fixed in the next newlib release... There shouldn't be any
serious bugs in the newlib headers... This is not the case with the
SunOS4.1.x, Solaris2 etc. proprietary headers.

 Perhaps the GCC-developers are planning to provide some 'generic standard
C headers', coming with GCC and to be installed into the TOOL_INCLUDE_DIR
($prefix/$target/include), so even the newlib and glibc headers would be
handled as 'third-party' headers and the '$prefix/$target/sys-include'
would then be the proper place for them... Currently both newlib and glibc
install their headers into the '$prefix/$target/include', so this isn't
acute now...

 Here is my '3rd-party' header directory for m68k under Windoze :

 Directory of E:\usr\local\m68k-coff\sys-include

[.]              [..]             328ads.h         68k.h
berr.h           bisync.h         board.h          bss.h
config.h         context.h        cpu32bug.h       dma.h
ether.h          ethernet.h       exception.h      fatal.h
gct.h            gpt.h            hdlc.h           hdlc_qmc.h
idsci.h          idsci_printf.h   leds.h           list.h
m68306.h         m68307.h         m68328.h         m68340.h
mc68230.h        mc68681.h        mc68681reg.h     mcf5206.h
mcf5307.h        mng.h            modules.h        msg.h
mtypes.h         online_r.h       pit.h            pram.h
protocol.h       qmc.h            qsm.h            quicc.h
register.h       registers.h      regs.h           scc.h
sim.h            sim5206.h        sim5307.h        simple.h
slot.h           smc_tm.h         smc_uart.h       states.h
status.h         threads.h        timer.h          timers.h
tm.h             tpu.h            tpuram.h         transp.h
types.h          uart.h

 Ie. consisting of all those 'chip-specific' headers etc. not coming with
the newlib headers but available from Motorola etc... Where you normally
put these 'system-specific' 3rd-party things? Among the newlib-headers or
where?  No recommendation seen ever...

 Any information about these things from the GCC-people would be needed
badly...

 BTW, what would be the opinion about adding/using the LOCAL_INCLUDE_DIR
also with a cross-compiler?  Everybody knows that the GPLUS_INCLUDE_DIR
(the C++ headers) is common for all GCCs in the system, but what is the
common directory for the C headers?

 If we think someone having a Linux/x86-host and wanting to produce stuff
for Windoze, Solaris2, other Linux'es (PowerPC, ARM,...) etc. using tcl/tk
etc. 'cross-platform'-tools, they have their own headers, installed into
the LOCAL_INCLUDE_DIR with a native GCC... But where to put these headers
with the cross-compilers?  Among the standard headers and then update them
all when updating the third-party-stuff ?

 Ok, I'll repeat my current search-scheme for 'm68k-coff', seen in my other
message...

E:\usr\local\lib\gcc-lib\m68k-coff\2_95.3>cpp0 -v
GNU CPP version 2.95.3 20010101 (prerelease) (68k, Motorola syntax)
#include "..." search starts here:
#include <...> search starts here:
 \usr\local\lib\gcc-lib\m68k-coff\2_95.3\..\..\..\..\include  <----- !!!
 \usr\local\lib\gcc-lib\m68k-coff\2_95.3\include
 \usr\local\lib\gcc-lib\m68k-coff\2_95.3\..\..\..\..\m68k-coff\sys-include
 \usr\local\lib\gcc-lib\m68k-coff\2_95.3\..\..\..\..\m68k-coff\include
End of search list.
The following default directories have been omitted from the search path:
 /usr/local/lib/gcc-lib/m68k-coff/2_95.3/../../../../include/g++-3
End of omitted list.

 As can be seen, the '/usr/local/include' (tidied...) is added into the
list and searched... (The GCC_EXEC_PREFIX adds the disk-name into these
four if used under Windoze...)

 What the possibilities could be for common C-headers with the embedded
targets, is unclear, but anyway it is there for them all... The 'include'
and 'sys-include' under $prefix/$target are now available for all... 

 Adding the LOCAL_INCLUDE_DIR only needs a little editing in the 'gcc/cccp.c'
and any person with a normal IQ can do that. The question is whether this
should or should not be done... And why the search paths for for a native-GCC
cannot be alike, only the absolute '/usr/include' added after the last ? (My
opinion is that the TOOL_INCLUDE_DIR is in the wrong place in a native GCC
now...)

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com