Re: Installation Problems

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

David Korn wrote:
> 
> >-----Original Message-----
> >From: Kai Ruottu [mailto:kai.ruottu@luukku.com]
> >Sent: 18 January 2001 10:12
> 
> >David Korn wrote:
> >>
> >>   Yep, it didn't find your target headers.  Contrary to what the docs
> >> tend to say, you should put them in $prefix/$target/sys-include, rather
> >> than $prefix/$target/include, or you can just tell the compiler where
> >> they are at configure time by adding the option
> >> --with-headers=/path/to/headers to your configure command.
> >
> > Sigh, I have tried to explain that the 'sys-include' is for the 3rd-party
> >headers used with a cross-compiler (the 'SYSTEM_INCLUDE_DIR'), while the
> >'include' is for the standard C headers (the 'STANDARD_INCLUDE_DIR').
> 
>     Kai, just a few points here...
> 
>   He *IS* building a cross compiler.  Now, I am under the impression that
> fixincs needs to be run on the standard C headers for a target board,
> because they often aren't 100% ANSI compatible, or need to be modified to
> reflect the different functionality that libgcc might provide compared to
> the OS vendors libs.  So I have the idea that fixincs must be run on the
> vendor headers a) in order to build libgcc correctly and b) in order to
> have valid headers that will work with gcc after installation.

 There are nothing like 'vendor headers' coming with GCC or newlib, although
I would wish there would be... All the 'chip-ABI' headers are missing, those
describing the I/O-port addresses in the microcontroller chips.

 If we take any commercial compiler aimed for embedded use, it has quite a
lot 'vendor headers' from the chip-maker. The Cygnus newlib has none...

 On this list I haven't seen anyone mentioning using any other C-library
for embedded use, although at least with MIPS the Algorithmics (www.algor.co.uk)
headers and libs could be considered as an alternative.

>   I am also firmly convinced (because I've tried it over and over again)
> that fixincs will never be run on the files in $prefix/$target/include, only
> on the files in $prefix/$target/sys-include.

 So the newlib and glibc headers shouldn't be put for fixing. Not before there
are sure information about that GCC needs to fix them.

>   Therefore, if the OS vendor headers are to be fixinc'd, they must be
> in sys-include.  And if they aren't to be fixinc'd, why does fixincl.x
> have OS vendor specific patches for systems such as VxWorks?

 Very old BSD-systems, Xenix/386, SCO Unix 3.2v[2-4] etc. from 80's and
early 90's may also have broken headers, just like VxWorks, but nowadays
probably 99% of the used target systems don't need the fixing. Or there
may be only one well-known bug which should or should not be fixed, a
newer release may have it already fixed... The recent NetBSD-case was one,
the version 1.3.2 headers from 1998 needed the fix while the 1.4.3 headers
from autumn-2000 didn't need it. However the target name is the same for
both. Fortunately the fix wouldn't break anything on the already fixed
header.

> >The system-dependent headers, ie. specific for just the one PC, should be
> >put into the 'sys-include'.
> 
>   I can't make sense of this, I'm afraid, "Specific for just the one PC",
> to me means 'this one here on my desk but not that identical one on the
> next desk'.  Unless these headers contain the hostname or other similar
> unique identifier I can't imagine what headers might meet this standard ?

 The standard headers belong to the C library, but there can be other add-on's
like tcl/tk, X11, all kind of GNOME, K-desktop etc. headers for Unix and Linux
targets, and of course all the headers from the chip-makers when using an
embedded target, which don't belong to the C-library... Putting them 'somewhere'
and pointing to them with '-I' is one solution, but as well they cold be
gathered into the SYSTEM_HEADER_DIR or SYSTEM_INCLUDE_DIR, whatever name will
be used for it.

 Basically the question is about the current practice... People have Cygwin
and Mingw targeted compilers under x86/Linux, for PowerPC/Linux, ARM/Linux,
MIPS/Linux targets too. And I haven't heard a case where the target headers
have been instructed to be put now into somewhere like:

  /usr/local/powerpc-linux/sys-include

 Here is a clip of the instructions from 'www.penguinppc.org' :

------------------ clip ---------------------------------------------------
Cross Compiling 

Cross Development mini-howto for Linux/PPC 

Updated Nov 2, 2000 

Originally written by Matt Porter 
Written and revised by Mark Hatle 

Copyright (c) 2000, penguinppc.org. 

<snip>

Header files from the PPC system in /usr/include, /usr/local/include, and
any subdirectories should be copied into

 /usr/local/powerpc-linux/include

on the host system. 
------------------ clip ---------------------------------------------------

 The Cygwin and Mingw cross-compiler instructions also talked about something like
'.../i586-cygwin/include' and '.../i386-mingw32/include' and so on, the Cygnus-
made Hitachi H8/300 and SH distributions use the 'include', the RedHat EDK-kit
uses the 'include'... So where on earth the 'sys-include' is used with a cross-
compiler?  Mumit Khan was one of those recommending using the 'sys-include' for
the target headers (when writing that the '--with-headers' is the current
recommendation), so I must check his cross-compiler instructions for Cygwin and
Mingw targets once more... 

 This goes now totally wrong, the people wanting to change the install directory
into the 'sys-include' should have some sane reason for this and they should
prove that the change is now necessary. The change happens when the '--with-headers'
will be used.  Could this be something called "change-over resistance" which we
older people are clained to have ;-) ?

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