cross-compiled native compiler: ld can't find crt1.o

[wim torfs]

||Martin Schaffner wrote:
||I'm trying to compile LFS starting from Mac OS X for my lfs-from-osx
||hint.
||
||I used crosstool (http://kegel.com/crosstool) to create a
||cross-compiler on Mac OS X for powerpc-750-linux-gnu, whose specs file
||I modify to use /tools/lib/ld.so.1 instead of /lib/ld.so.1.
||With this cross-compiler, I compiled glibc-2.3.2 (as patched for
||crosstool), gcc-3.3.3 and binutils-2.14 (patched and compiled as
||in the sections "Pass 2" of LFS-5.1.1 plus the host and build
|| configure |flags).
||
||After starting Linux with init=/tools/bin/bash, the compiler
||in /tools/ can compile a hello world program fine, but it can't
||link it.
||
||The first problem is that in the arguments to ld, gcc passes crt0.o,
||crt1.o, and crtn.o directly, without any path prefixed, so ld can't
||find them.


|Heh. I've run into that. It means your toolchain is not installed
|quite right.
|The -print-file-name option to gcc can be used to check whether gcc can
|find
|a particular file. e.g.
|$ gcc -print-file-name=crt1.o
|/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crt1.o
|If it can't find it, it'll print it out with just a bare filename,
|just as you're seeing.


|The way to solve this is to look at the gcc source code to understand
|what the -print-file-name= option does, and work backwards from there.
|It's not fun, but hey, at least you get to see how things work.
|- Dan


I'm sorry, I'm new to this matter, but I have the same problem.

I looked as Dan mentioned to the file gcc passed to ld.
It searches somewhere in my /usr/lib/gcc/... directory.
the crt1.o file isn't there, it is positioned in the /usr/lib directory.

agreed until there, the linker can't find the crt1.o file.

there is one thing though that I don't quite get.

I've build the kernel headers, binutiles, glibc-headers and gcc(first
step).
That arm-linux-gcc is looking in /usr/lib/gcc/...
when I build glibc for running on an ARM target, I get stuck at the
configure step, because there is a test for calculating the size of a
long, where it uses the arm-linux-gcc, hence the configure step fails.

If I'm right, the crt1.o is generated by the glibc install.

Now my question: should the arm-linux-gcc search for the
/usr/lib/gcc.../crt1.so or the one generated by the arm compiled glibc?
I thought the second one, but how to compile glibc when there is no
crt1.o yet???



Wim






------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-***@sources.redhat.com

[Arno Schuring]

see below

----- Original Message -----
From: "wim torfs" <***@pandora.be>
To: <***@sources.redhat.com>
Sent: Saturday, August 28, 2004 1:13 PM
Subject: Re: cross-compiled native compiler: ld can't find crt1.o

Post by wim torfs
||I'm trying to compile LFS starting from Mac OS X for my lfs-from-osx
||hint.

yay! I did the same from i386->sparc

(...)

Post by wim torfs
||
||The first problem is that in the arguments to ld, gcc passes crt0.o,
||crt1.o, and crtn.o directly, without any path prefixed, so ld can't
||find them.
|Heh. I've run into that. It means your toolchain is not installed
|quite right.
|The -print-file-name option to gcc can be used to check whether gcc can
|find
|a particular file. e.g.
|$ gcc -print-file-name=crt1.o
|/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crt1.o
|If it can't find it, it'll print it out with just a bare filename,
|just as you're seeing.
|The way to solve this is to look at the gcc source code to understand
|what the -print-file-name= option does, and work backwards from there.
|It's not fun, but hey, at least you get to see how things work.
|- Dan

A quick (dirty) solution is to edit the gcc specs file. Look for the *link:
target:

*link:
%{!static:--eh-frame-hdr} -m elf32_sparc (...)

You can add -Y P,[override-path-to-library] here.
It's probably not wise to do this for your definitive toolchain (it
overrides all paths you may have used when configuring binutils), but for
example the LFS /tools toolchain works fine. Actually, I did the same thing
when "re-adjusting the toolchain": I added -Y P,/lib:/usr/lib instead of
re-building binutils.

Post by wim torfs
I'm sorry, I'm new to this matter, but I have the same problem.
I looked as Dan mentioned to the file gcc passed to ld.
It searches somewhere in my /usr/lib/gcc/... directory.
the crt1.o file isn't there, it is positioned in the /usr/lib directory.
agreed until there, the linker can't find the crt1.o file.

If this is a temporary toolchain, consider the above alternative instead of
recompiling everything.

Post by wim torfs
there is one thing though that I don't quite get.
I've build the kernel headers, binutiles, glibc-headers and gcc(first
step).
That arm-linux-gcc is looking in /usr/lib/gcc/...
when I build glibc for running on an ARM target, I get stuck at the
configure step, because there is a test for calculating the size of a
long, where it uses the arm-linux-gcc, hence the configure step fails.
If I'm right, the crt1.o is generated by the glibc install.

You are right

Post by wim torfs
Now my question: should the arm-linux-gcc search for the
/usr/lib/gcc.../crt1.so or the one generated by the arm compiled glibc?
I thought the second one, but how to compile glibc when there is no
crt1.o yet???

You probably forgot to supply the --build directive. Only when both --host
and --build are supplied (and are different), glibc configures itself for
cross-compilation. (And so, does not run those tests)

HTH,
Arno

Post by wim torfs
Wim

------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-***@sources.redhat.com

[wim torfs]

Post by Arno Schuring
You probably forgot to supply the --build directive. Only when both --host
and --build are supplied (and are different), glibc configures itself for
cross-compilation. (And so, does not run those tests)
HTH,
Arno

Thanks, that did the thing.

I was wondering, I finally managed to compile the glibc, but had to do
some tricks. Could someone confirm this is normal or not?

I used binutils-2.15.91.0.1, gcc-3.4.1, glibc-2.3.3 and kernel-2.6.7

I know, I 'm making it hard by using the latest sources, but I'm using
it for my thesis and I would like to do 'real time' stuff on an arm.
therefore, my opinion was that by taking the latest sources, that there
would be more support in the sources for rt stuff. Not sure whether this
is right though??


anyway, here are the thing I 've done, I would appreciate it if someone
could tell me whether this is ok (or not).

I'm compiling for the S3C4530 (samsung arm without mmu)
I haven't done any cpu optimization yet, I first wanted to make a
working toolchain.
I based my commands mostly on the crosstool.sh, as many of you will
notice.


environent variables:

TARGET=arm-linux
PREFIX=/opt/arm/tools
TARGET_PREFIX=$PREFIX/$TARGET

mkdir -p $TARGET_PREFIX/include/gnu
mkdir -p $TARGET_PREFIX/lib
mkdir -p $TARGET_PREFIX/usr/lib

1) kernel headers:

patch linux 2.6.7 kernel with linux-2.6.7-hsc0.patch
(patch for the kernel to support nommu archs)

$ cd linux-2.6.7
$ make ARCH=armnommu menuconfig
$ make ARCH=armnommu include/asm \
include/linux/version.h \
include/asm-armnommu/.arch

$ cp -r include/linux $TARGET_PREFIX/include
$ cp -r include/asm $TARGET_PREFIX/include/asm
$ cp -r include/asm-generic $TARGET_PREFIX/include
$ cp -r include/asm-arm $TARGET_PREFIX/include

the last step is necessary because armnommu refers to asm-arm




all further compiles happen in a separate build dir

2) binutils-2.15.91.0.1

$ ../binutils-2.15.91.0.1/configure --prefix=$PREFIX \
--target=$TARGET \
--disable-nls \
--with-sysroot=$TARGET_PREFIX

$ make all
$ make install


3) glibc headers

$ CC=gcc ../glibc-2.3.3/configure --prefix=/usr \
--host=$TARGET \
--build=i686-linux \
--disable-sanity-checks \
--with-headers=$TARGET_PREFIX/include

$ make sysdeps/gnu/errlist.c
$ mkdir stdio-common
$ touch stdio-common/errlist-compat.c
$ make cross-compiling=yes \
install_root=$TARGET_PREFIX \
prefix="" \
install-headers

$ touch $TARGET_PREFIX/include/gnu/stubs.h
$ cp ../glibc-2.3.3/include/features.h $TARGET_PREFIX/include
$ cp bits/stdio_lim.h $TARGET_PREFIX/include/bits





4)gcc-3.4.1 first time

$ ../gcc-3.4.1/configure --prefix=$PREFIX \
--target=$TARGET \
--build=i686-linux \
--with-local-prefix=$TARGET_PREFIX/include \
--disable-multilib \
--with-newlib \
--with-headers=$TARGET_PREFIX/include \
--disable-nls \
--disable-threads \
--disable-shared \
--enable-languages=c

$ make all-gcc
$ make install-gcc



5) glibc-2.3.3 full install

->patch1: (resolves BUS_ISA undeclared error)
$ vi ../glibc-2.3.3/sysdeps/unix/sysv/linux/arm/ioperm.c

add:
#include <linux/input.h>

->patch2: (resolves fallback_frame_state_for undeclared)
$ touch ../glibc-2.3.3/sysdeps/arm/framestate.c

->patch3: (resolves ld: cannot find -lgcc_eh)
$ vi ../glibc-2.3.3/Makeconfig

change the line
gnulib := -lgcc -lgcc_eh
into
gnulib := -lgcc


$ BUILD_CC=gcc CFLAGS="-O" CC=$TARGET-gcc \
AR=$TARGET-ar RANLIB=$TARGET-ranlib \
../glibc-2.3.3/configure --prefix=/usr
--host=$TARGET
--build=i686-linux
--enable-kernel=2.4.18
--without-cvs
--without-tls
--enable-shared
--without-__thread
--without-gd
--with-headers=$TARGET_PREFIX/include
--enable-add-ons=linuxthreads

$ make LD=$TARGET-ld RANLIB=$TARGET-ranlib
$ make install install_root=$TARGET_PREFIX prefix=""


$ for file in libc.so libpthread.so libgcc_s.so; do
for lib in lib usr/lib; do
if test -f $TARGET_PREFIX/$lib/$file &&
test ! -h $TARGET_PREFIX/$lib/$file; then
mv $TARGET_PREFIX/$lib/$file \
$TARGET_PREFIX/$lib/${file}_orig
sed 's@/usr/lib/@@g;s@/lib/@@g; \
/BUG in libc.scripts.output-format.sed/d' \
<$TARGET_PREFIX/$lib/${file}_orig> \
$TARGET_PREFIX/$lib/$file
fi
done
done



6) gcc-3.4.1

$ ../gcc-3.4.1/configure --prefix=$PREFIX
--target=$TARGET
--with-headers=$TARGET_PREFIX/include
--with-local-prefix=$TARGET_PREFIX/include
--disable-nls
--enable-threads=posix
--enable-symvers=gnu
--enable-__cxa_atexit
--enable-languages=c,c++
--enable-shared
--enable-c99
--enable-long-long

$ make all
$ make install




afterwards, I can compile a simple hello world file, but I have the
feeling that the libraries for c++ aren't compiled in.
(iostream.h isn't recognised)



What did I do wrong?

thanks for any response

Wim





------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-***@sources.redhat.com