Getting started ( again )

[Kai Ruottu]

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