Pandora Pandora Toolchain, how to build crt1.o/crti.o/etc.?

[Rockthesmurf]

I've built an arm-none-linux-gnueabi toolchain under OSX (as a bit of an experiment really), however when I try to use the toolchain to build, the linker complains about missing crt files, for example:

macandora-dev scraft$ ~/toolchain/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc main.c
/Users/scraft/toolchain/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.2.2/../../../../arm-none-linux-gnueabi/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
It isn't lying either:

mac:pandora-dev scraft$ find ~/toolchain/arm-none-linux-gnueabi/ -name "crt1.o"
mac:pandora-dev scraft$

If I check other toolchains:

mac:pandora-dev scraft$ find ~/pandora-dev/arm-2011.09/ -name "crt1.o"
/Users/scraft/pandora-dev/arm-2011.09//usr/lib/crt1.o
/Users/scraft/pandora-dev/arm-2011.09//var/usr/lib/crt1.o

I'm not really sure where the crt*.o files are meant to come from (newlib perhaps?). If I build an 'arm-elf' toolchain, I am able to build and link successfully, from having a look on Google, there is some suggestion that if one builds a linux based toolchain (arm-none-linux-gnueabi) there is an assumption you are doing an upgrade and will have the crt*.o files available from the OS (or something), where as if you build a bare metal tool chain (arm-elf) then it assumes there is no OS to get these runtime files from. The big disclaimer is I don't know anything about building toolchains, so any friendly advise is welcome!
For reference, below is my script to build the toolchain:

Spoiler

set -e
curl -O ftp://gcc.gnu.org/pub/binutils/releases/binutils-2.18.tar.bz2
curl -O ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.2.2/gcc-core-4.2.2.tar.bz2
curl -O ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.2.2/gcc-g++-4.2.2.tar.bz2
curl -O http://mirrors.usc.edu/pub/gnu/gdb/gdb-6.7.1.tar.bz2
curl -O ftp://sources.redhat.com/pub/newlib/newlib-1.16.0.tar.gz

tar -xjf binutils-2.18.tar.bz2
tar -xjf gcc-core-4.2.2.tar.bz2
tar -xjf gcc-g++-4.2.2.tar.bz2
tar -xjf gdb-6.7.1.tar.bz2
tar -xzf newlib-1.16.0.tar.gz

# Set up target, prefix and put toolchain bin directory into path.
export target=arm-none-linux-gnueabi
export prefix=`dirname \`pwd\``/`basename \`pwd\``/$target
rm -fr $prefix/bin
mkdir -p $prefix/bin
export PATH=$prefix/binPATH

# Binutils.
cd binutils-2.18
rm -fr build-$target
mkdir build-$target
cd build-$target/
../configure --target=$target --prefix=$prefix --enable-interwork --enable-multilib --disable-nls \
--disable-shared --disable-threads --with-gcc --with-gnu-as --with-gnu-ld --disable-werror
make -j32
make install
cd ../..

# Build boot strap compiler.
cd gcc-4.2.2
rm -fr build-$target
mkdir build-$target
cd build-$target
../configure --target=$target --prefix=$prefix \
--disable-nls --disable-shared --disable-threads \
--with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2 \
--enable-languages=c,c++ --enable-interwork \
--enable-multilib --with-newlib \
--with-headers=../../newlib-1.16.0/newlib/libc/include \
--disable-libssp --disable-libstdcxx-pch \
--disable-libmudflap --disable-libgomp -v
rm -fr libiberty libcpp fixincludes
mkdir -p libiberty libcpp fixincludes
make all-gcc -j32
make install-gcc
cd ../..

# Newlib.
cd newlib-1.16.0
rm -fr build-$target
mkdir build-$target
cd build-$target
../configure --target=$target --prefix=$prefix --enable-interwork --enable-multilib
make -j32
make install
cd ../..

# Full compiler.
cd gcc-4.2.2/build-$target
make -j32
make install
cd ../..

# Gdb.
cd gdb-6.7.1
rm -fr build-$target
mkdir build-$target
cd build-$target
../configure --target=$target --prefix=$prefix --disable-nls
make -j32
make install
cd ../..

# Strip.
strip $prefix/bin/*
strip $prefix/$target/bin/*
strip $prefix/libexec/gcc/$target/4.2.2/*

I actually have to patch newlib before building for arm-none-linux-gnueabi (not listed above, and not required for arm-elf), the patch is to tell it to copy the elf-linux.spec when libgloss is being installed (otherwise it moans there is no linux.spec file available).

 

[sebt3]

For what I know, crt*o files come with glibc and need to be from the same version as the library (but I might be completly wrong here).

Wasn't it you that worked on a windows toolchain ? I seems to remember that this thread talked about that issue.

 

[Rockthesmurf]

I have a Windows toolchain which works fine for my own projects (I just use the Code Sourcery compiler and base headers, along with library headers/libs from a random Linux toolchain I found knocking around for Linux). The main problem with a pure windows toolchain (not cygwin) is that a lot of open source projects rely on various tools that aren't available on windows (autoconf, symbolic links using ln -s, etc.). I have a powerful Mac build server knocking around and thought it could be interesting to have it usable to make Pandora builds.

From doing more reading today, it *seems* like newlib is designed for bare metal development, but not Linux development. For Linux developing glibc is preferable (or another variation, which there are many). One problem is that glibc seems to be a lot harder to build that newlib (as in guides I have seen so far include copying stuff over from the target OS, which isn't really something I am that keen on doing).

I have just grabbed the Code Sourcery source, I am wondering if I can compile this into a usable OSX tool chain.