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] |
Alvaro <alvaro.garriga@transcore.com> wrote: > I need help compiling gcc as a cross compiler for the m68k platform. > I have tried to compile gcc-2.95.3 from the source as a cross compiler > for the m68k platform but I am running into trouble. > > --target=m68k-wrs-vxworks to ./configure > I got compile errors when it failed to find stdlib.h ( > which was in /usr/local/include ) As Aaron told, the VxWorks target headers and libs should be used during the build... The C-headers really aren't 'generic' and common for all targets, although the name "standard C headers" will be used with them... Or some people use the name "system C headers"... And all this is the endless source of discussion ;-) Anyway the GCC- manual tells now the following for the native GCC: ------------------- clip ------------------------------------------ SYSTEM_INCLUDE_DIR Define this macro as a C string constant if you wish to specify a system-specific directory to search for header files before the standard directory. SYSTEM_INCLUDE_DIR comes before STANDARD_INCLUDE_DIR in the search order. Cross compilers do not use this macro and do not search the directory specified. STANDARD_INCLUDE_DIR Define this macro as a C string constant if you wish to override the standard choice of /usr/include as the default prefix to try when searching for header files. Cross compilers do not use this macro and do not search either /usr/include or its replacement. ------------------- clip ------------------------------------------ The SYSTEM_INCLUDE_DIR is not normally defined and in use, so the '/usr/include' is the only one used... Unfortunately this is not so simple with cross-compilers which even use different names for these 'include' directories, the names CROSS_INCLUDE_DIR and TOOL_INCLUDE_DIR, but the places and search order are the same... Cross-compilers search their 'system' and 'standard' headers from: $prefix/$target/sys-include and $prefix/$target/include and just in this order... In your case (no '--prefix=$prefix' given) these are: /usr/local/m68k-wrs-vxworks/sys-include and /usr/local/m68k-wrs-vxworks/include so you should preinstall the VxWorks-headers there... And because the VxWorks headers are expected being broken for GCC, the 'sys-include' is the right place now. If they weren't broken, like is the case with the 'newlib' or 'glibc' headers, the right place would be the 'include'. The GCC-build tries to 'fix' all the headers in 'sys-include' and all the "don't fix if it ain't broken" stuff is wiser to be hided into the 'include' (The gcc-3.x build will really spoil a couple of newlib headers, if allowed to be 'fixed'). The exception is the 'limits.h' which should be seen in the 'sys-include', it the 'standard C headers' have this. This is the case with glibc and Linux... This is somehow complicated but not so many seem to care... The GCC-manual doesn't tell anything else about the 'sys-include', than that "GCC doesn't install anything there" : ------------------- clip ------------------------------------------ CROSS_INCLUDE_DIR is used only for a cross compiler. GNU CC doesn't install anything there. TOOL_INCLUDE_DIR is used for both native and cross compilers. It is the place for other packages to install header files that GNU CC will use. 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. ------------------- clip ------------------------------------------ So the GCC-manual clashes with what I previously wrote... The 'fixincludes' really doesn't process any headers in TOOL_INCLUDE_DIR but in CROSS_INCLUDE_DIR now. So one could tell that the current GCC- build clashes with the current GCC-manual... I have sent at least twice a bug report about this mess with the header-fixing, but got no feedback... (Or it was seen only on the 'gcc-bug'-list I haven't subscribed...) Ok, the C++ headers are normally mixed with the C-headers in the VxWorks-headers ('.../h/...') and these should be removed because every GCC-version comes with its own 'libstdc++' and its "Standard C++ Headers". The old C++ headers must not be found before the GCC- ones... > 2- Where can i find information about it on the web. all that I have > found seems out dated. When you have the GCC-sources, you have the unbuilt GCC-manual in 'gcc-2.95.3/gcc/gcc.texi', and you can produce HTML-docs for Netscape etc. using 'texi2html', or a PDF-doc for Acrobat using 'pdftex'. Of course using 'TeX' is an art of its own, the 1st 'pdftex gcc.texi' gives only a rough manual without any indeces, so the produced 'gcc.cp' ("Concept") etc. index-files must be sorted with 'texindex' and the 'pdftex gcc.texi' run once again for the final manual. But generally producing a 'gcc.pdf' is not hard at all... After this one probably wants to do the same with the binutils docs, the GDB docs etc. The GCC-manual and the "Install / Cross-Compiler" there really should be the 1st-to-read in this issue, about "what are the suitable headers, libraries" etc. for a target. It can be possible that the "Porting" parts (which have the "Installation") are not built as default and the beginning of the 'gcc/gcc.texi' should be edited. Hmmm... ---------------------- clip -------------------------------- \input texinfo @c -*-texinfo-*- @c %**start of header @setfilename gcc.info @c @setfilename usegcc.info @c @setfilename portgcc.info @c To produce the full manual, use the "gcc.info" setfilename, and @c make sure the following do NOT begin with '@c' (and the @clear lines DO) @set INTERNALS @set USING @c To produce a user-only manual, use the "usegcc.info" setfilename, and @c make sure the following does NOT begin with '@c': @c @clear INTERNALS @c To produce a porter-only manual, use the "portgcc.info" setfilename, @c and make sure the following does NOT begin with '@c': @c @clear USING ---------------------- clip -------------------------------- Asking a 'stupid question' here about getting only the "Using the GNU Compiler Collection (GCC)", should normally solves this problem, if there is a problem as I remember... Ok, some basic instructions were given, but the archives of this list should tell more, just search for 'vxworks'... In any case this target really is not one of the easiest targets. 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] |