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] |
Other format: | [Raw text] |
Rupert Wood wrote: > > Kai Ruottu wrote: > > > > $prefix (=foo/myGCC). That works fine. Then I put the /usr/include > > > tree from solaris into foo/myGCC/sparc-sun-solaris2.8/sys-include/ > > > > Please check what the aim for the '$prefix/$target/sys-include' is, > > and what for the '$prefix/$target/include'... > > > > RTFM, "Standard Header Directories"... > > I think I'm the one responsible for giving him this advice. I concede > didn't RTFM "System Header Directories". However, sys-include is *not* > SYSTEM_INCLUDE_DIR; it is [CROSS_]SYSTEM_HEADER_DIR. > > The "--with-headers" configure option copies the path specified to > sys-include. This directory is processed by fixincludes at build time. > This is all correctly documented in the manual. You mean the text starting with this in the "Using and Porting...." from Stallman and other GCC-developers? (I understand the 'manual' meaning the official '.texi'-files coming with the GCC-sources, not the 'opinions' from single persons in some FAQs in the net...) ---------------------------- clip ------------------------------------- Standard Header File Directories GCC_INCLUDE_DIR means the same thing for native and cross. It is where GNU CC stores its private include files, and also where GNU CC stores the fixed include files. A cross compiled GNU CC runs fixincludes on the header files in $(tooldir)/include. (If the cross compilation header files need to be fixed, they must be installed before GNU CC is built. If the cross compilation header files are already suitable for ANSI C and GNU CC, nothing special need be done). ---------------------------- clip ------------------------------------- So what the current 'gcc/Makefile' now does, clashes with the 'manual' and to understand this, one may have several theories: - in order to not spoil the 'already suitable' newlib and glibc headers, installed into '$(tooldir)/include' by their own 'make install', when built, they will now be 'hided' from the 'fixincludes' by putting it to search where nothing should be... "CROSS_INCLUDE_DIR is used only for a cross compiler. GNU CC doesn't install anything there." This sounds sane, although for which purpose a cross-compiler would use it was left unknown... (My guess has been 'for system-specific', ie. for the 'local' purposes for which the 'LOCAL_INCLUDE_DIR' is aimed with the native-GCC). - someone didn't see the difference between 'system' and 'standard' and thought the '$(tooldir)/sys-include' really being the 'normal' and de-facto standard for installing the 'standard C headers' for the cross- target... And the same person invented the '--with-headers' and put it to copy the standard C-headers for the target into the 'sys-include'... More mess will cause the fact that the produced main Makefile and the 'gcc/Makefile' use the option '-I$(build_tooldir)/include' for searching the target headers during the build... If the headers are in the '$(tooldir)/sys-include', this doesn't work and is vain. Earlier the '$prefix/lib/gcc-lib/$target/$gcc_version' wasn't created during the build and this option was necessary, but then it pointed to the wrong place if the aim was to start to use the 'sys-include', not the 'include'... Now it is vain because both the 'include' and 'sys-include' will be found because the '$prefix/lib/gcc-lib/$target/$gcc_version' will be pre-created during the GCC-build... It is true that many targets still need their 'standard C-headers' being fixed for GCC, but if one uses already fixed headers with an already installed cross-compiler and these will again be fixed, the result is a mess. I also wouldn't trust GCC 'fixing' the up-to-date glibc and newlib headers, these should be 'already suitable'... With the Linux-targets I have seen GCC trying to fix also the 'include/asm' and 'include/linux' and put them into the GCC_INCLUDE_DIR... These just happened to be there during the build, symlinked from the kernel sources then, but after the GCC-install the kernel sources may be updated many times, and the symlinks in '$prefix/$target/include' updated too, but all the time the old 'fixed' kernel headers will be used instead. I have experimented with the headers-fixing sometimes... So 'hiding' the standard C-headers from 'fixincludes' during the GCC-build, so never using the '--with-headers=' or preinstalling the target headers into the '$prefix/$target/sys-include', but preinstalling them into the '$prefix/$target/include', is my advice... BUT if one wants to experiment with the header-fixing, the results MUST be checked and manually fixed to be sane... The 'limits.h' and 'math.h' in the Solaris2 case are well-known for needing to be 'seen' and fixed (the 'struct exception' in 'math.h'), so these should be seen in the 'sys-include' during the build. The situation with the placement of the target headers is a mess and quite a lot must be done with standardizing it... "Become familiar with the target before trying to aim to it", would be a good advice... In the Solaris2-case the "Solaris2-FAQ" is a must, and one must have some kind of thought about where to put all the stuff which doesn't exist in '/usr/include' and '/usr/lib' (or were these at '/usr/ccs/...'?), like the X11-stuff, 'dt', 'openwin' etc. > The compiled-in directory search order for cross-compilers looks a bit odd, > though: that might need some attention and/or fixing. Just as the one for a native GCC, the gcc-3.x has already changed the TOOL_INCLUDE_DIR to be after the GCC_INCLUDE_DIR. In gcc-2.95.x it still was before it... I would add the LOCAL_INCLUDE_DIR also for cross-compilers and add the CROSS_INCLUDE_DIR for native compilers, so the only difference between a native and a cross-compiler would be that the native one still searches from '/usr/include' after all the same directories present in a cross-compiler... If one has tools for five Linux-targets (e.g. PPC, ARM, MIPS, x86_64, ia64) and concentrates to a single kernel version at a time, having the kernel headers in 'LOCAL_INCLUDE_DIR/linux' and 'LOCAL_INCLUDE_DIR/asm-*' would be much better organized than having these splitted into separate places... A single tcl/tk-version, GUI-toolkits etc. common for them all too... But if one would like the target-specific headers be included before the 'common' ones, the '$prefix/$target/*include' should be searched before the LOCAL_INCLUDE_DIR... So I must agree with your "might need some attention and/or fixing" and add the word "still"... > I concede that I've gained more of my knowledge of cross toolchains from > experimentation and reading the configure scripts rather than reading > the manual. I'm welcome to correction or advice. My opinion is that the GCC-manual and what happens during the build shouldn't clash this badly... The manual ('install.texi') and the sources are easy to fix, we are talking about 'Open Software', not anything for which only a preprinted manual and prebuilt binaries are available... Of course anyone can fix these bugs and start distributing 'fixed' GNU-sources and 'fixed' GNU manuals which are compatible with each others... But is this sane ? Reporting this clash between the GCC-manual and the GCC-sources hasn't yet caused any actions from the GCC-developers... BTW, one earlier suggestion for the manual in this issue follows: ---------------------------- clip ------------------------------------- Standard Header File Directories GPLUSPLUS_INCLUDE_DIR means the same thing for native and cross. It is where the C preprocessor (earlier named as cpp, now cpp0) looks first for the standard C++ header files. The standard C++ library installs only target independent header files into this directory. The name of this directory will be different with the versions of the standard C++ library, but generally it is a subdirectory under the LOCAL_INCLUDE_DIR ($(local_prefix)/include). LOCAL_INCLUDE_DIR means the same thing for native and cross. GNU CC doesn't install anything there. It is where the C preprocessor (earlier named as cpp, now cpp0) looks first for the C header files (and next with C++). Only the target independent C header files should be installed into this directory. It is normally set to be the $(local_prefix)/include. Users can install their target independent 3rd party header files (like tcl/tk, GUI-toolkits etc.) into this directory. GCC_INCLUDE_DIR means the same thing for native and cross. It is where GNU CC stores its private include files, and also where GNU CC stores the fixed include files. A GNU CC build as a cross compiler runs fixincludes on the header files in $(tooldir)/include. It does not matter if the target header files there need to be fixed or not, they must anyway be installed there before the GNU CC build is started. There are also some header files like the limits.h whose existence among the target header files will be checked and the private headers in GNU CC will be modified accordingly. If the target header files are already suitable for ISO C and GNU CC, nothing special need to be done to fix them. The GCC_INCLUDE_DIR comes after the directory LOCAL_INCLUDE_DIR in the C headers search order. CROSS_INCLUDE_DIR means the same thing for native and cross. GNU CC doesn't install anything there. It is where the C preprocessor (earlier named as cpp, now cpp0) looks for the C header files after the GCC_INCLUDE_DIR. Only the target dependent C header files not belonging to the standard C headers for the target (like the CPU- and I/O-ports describing headers from the chip-makers) should be installed into this directory. It is normally set to be the $(tooldir)/sys-include. STANDARD_INCLUDE_DIR is used only by native compilers. When you build a native compiler, fixincludes processes any header files in this directory. It is where the C preprocessor (earlier named as cpp, now cpp0) looks for the C header files after the CROSS_INCLUDE_DIR. It is normally set to be the /usr/include. TOOL_INCLUDE_DIR is used only by cross compilers. For a cross-compiler, this is the equivalent of /usr/include. When you build a cross-compiler, fixincludes processes any header files in this directory. It is where the C preprocessor (earlier named as cpp, now cpp0) looks for the C header files after the CROSS_INCLUDE_DIR. It is normally set to be the $(tooldir)/include. ---------------------------- clip ------------------------------------- Currently enabling the TOOL_INCLUDE_DIR for a native compiler too, would be my suggestion... This and STANDARD_INCLUDE_DIR being 'equivalents' or alternatives told that they both couldn't be present, but when nowadays a native Linux-GCC has this always empty, why then not in the future, until someone finds a suitable use for it... Here is the 'cpp0'-output from a cross-GCC I recently built: ---------------------------- clip ------------------------------------- H:\usr\local\lib\gcc-lib\x86_64-linux-gnu\3.1>cpp0 -lang-c++ -v GNU CPP version 3.1 20020408 (prerelease) (cpplib) (x86-64 Linux/ELF) ignoring nonexistent directory "/usr/local/include/g++-v3/x86_64-linux-gnu" ignoring nonexistent directory "NONE/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include/g++-v3 /usr/local/include/g++-v3/backward /usr/local/include /usr/local/lib/gcc-lib/x86_64-linux-gnu/3.1/include /usr/local/x86_64-linux-gnu/sys-include /usr/local/x86_64-linux-gnu/include End of search list. ---------------------------- clip ------------------------------------- From where on the earth the "NONE/include" comes, hasn't yet come clear to me... Ok, it and the 'GPLUSPLUS_INCLUDE_DIR/backward' could be documented in the gcc-3.1-texinfo's now... As usually just building the binaries, not the manual, has been done. Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |