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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |