This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: FW: GCC Cross Compiler for cygwin
- From: Kai Ruottu <karuottu at mbnet dot fi>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 02 May 2005 13:43:47 +0300
- Subject: Re: FW: GCC Cross Compiler for cygwin
- References: <2880F931F603D543B2A5490852E3E3F5833EB8@iridium.thx.com> <427184D4.2070507@specifixinc.com>
- Reply-to: karuottu at mbnet dot fi
James E Wilson kirjoitti:
Amir Fuhrmann wrote:
checking whether byte ordering is bigendian... cross-compiling...
unknown
checking to probe for byte ordering...
/usr/local/powerpc-eabi/bin/ld: warning: cannot find entry symbol
_start; defaulting to 01800074
Looking at libiberty configure, I see it first tries to get the
byte-endian info from sys/params.h, then it tries a link test. The
link test won't work for a cross compiler here, so you have to have
sys/params.h before building, which means you need a usable C library
before starting the target library builds. But you need a compiler
before you can build newlib.
You could try doing the build in stages, e.g. build gcc only without
the target libraries, then build newlib, then build the target
libraries. Dan Kegel's crosstool scripts do something like this with
glibc for linux targets.
A "complete" (with libiberty and libstdc++) newlib-based GCC should be
got when using the '--with-newlib' in the
GCC configure. But there are long-standing bugs in the GCC sources and
workarounds/fixes are required. But
only two :
1. For some totally wacky reason the GCC build tries to find the target
headers in the '$prefix/$target/sys-include'
instead of the de-facto standard place (where the newlib install
will also put them), '$prefix/$target/include'. So
either all the target headers should be seen in the 'sys-include'
too -- but one cannot be sure about the newlib
case -- or only the absolutely required ones: 'limits.h', 'stdio.h',
'stdlib.h', 'string.h', 'time.h' and 'unistd.h', the rest
being only in the '$prefix/$target/include'. Putting only these 6
headers into the 'sys-include', by symlinking or
copying them there, is my recommendation for current GCC sources
(3.2 - 4.0).
2. The 'libiberty' config stuff claims that newlib has not the functions
'asprintf()', 'strdup()' and 'vasprintf()'. Finding
the place for the "list of missing functions in newlib" is easy,
just using 'grep newlib' in the 'libiberty' subdir and
checking the shown files and then fixing them. So the
'--with-newlib' works now like if some 5 or so years old
newlib would be used... Not fixing may work sometimes, sometimes
the protos in the newlib headers will clash
with the function (re)implementations in libiberty...
Otherwise the GCC build follows the instructions given in the GCC
manual (when it still was only one, with gcc-2.95).
Preinstalling binutils and what one has available for the target C
library, in the newlib case the generic newlib headers
found in 'newlib-1.13.0/newlib/libc/include' in the current '1.13.0'
sources, are the prerequisites for the GCC build..
Of course the used '$prefix' should replace the '/usr/local' (the
default $prefix) used in the GCC manual instructions.
After doing the previous two workarounds and using '--with-newlib' in
the configure command a newlib-based GCC
build should succeed nicely... At least the 'powerpc-eabi' case plus
all those tens of other targets I have tried "from
scratch"....
Although one would already have a self-built newlib (with some older
GCC) when updating the GCC, using the
'--with-newlib' may still be obligatory. Targets like 'powerpc-eabi' are
not real targets, one cannot create executables
for them because there is no default target board with default glue
library (low-level I/O, memory handling etc.)....
But believe me, quite many still expect all kind of elves being real
targets, 'arm-elf', 'sh-elf', 'h8300-elf' etc. maybe
behave like being 'real' targets, but 'm68k-elf', 'mips-elf', 'arc-elf'
etc. are totally unreal... The 'eabi' being just one
kind of 'elf' and it being real is also very common. But one must use
options for '-mads', a Yellow Knife
(-myellowknife) or something in order to get the right libraries taken
with the linking... Shortly said the '--with-newlib'
should remove all the checks for the target libraries and describe the
'newlib' properties in the GCC config scripts, so
building a "complete" GCC with 'libiberty' and 'libstdc++' should
succeeed when only having the generic newlib
headers preinstalled (plus the binutils) before starting the GCC build.
After getting GCC built and installed, one can build and install the C
library, newlib'. And then try the almost
obligatory "Hello World" and see if one's "elf" is a real creature or
then not... As told the "eabi" is not and one must
use a wacky command like :
powerpc-eabi-gcc -mads -O2 -o hello_ppc-eabi.x hello.c
or
powerpc-eabi-gcc -myellowknife -O2 -o hello_ppc-eabi.x hello.c
when trying to compile and link the "Hello World"... The GCC manual
documents the supported boards for PPC
EABI quite well, for other targets one may need to know more about
adding linker scripts, libraries etc. in the
command line, how to fix the 'specs' and add a default target into it...
Or something....