This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |