This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

--with-sysroot required when building 32->64 bit crosstoolchain?(was: building a cross-compiler is hard)


http://sources.redhat.com/ml/binutils/2003-08/msg00225.html
suggests that the only way to build a 32 -> 64 bit cross toolchain
is to use --with-sysroot!
http://viz.cacr.caltech.edu/tiki/tiki-index.php?page=BinutilsPk seems to come to a similar conclusion.

Since --with-sysroot is only supported by gcc-3.3.3 and higher,
I'd have to complicate my toolchain build script to use it.
It'd be nice if there were a way to just selectively add lib64 to
the linker's search path on 32 -> 64 bit cross toolchains.
What's so wrong with the approach H.J.Lu originally tried,
http://sources.redhat.com/ml/binutils/2003-08/msg00219.html ?

Grumble.  I guess I'll sit down and see what breaks when I
try --with-sysroot.  Been putting that off for about a year now...
- Dan

p.s. Here's how I came across this, in case anyone cares.  I wrote this up while
I was figuring things out, may as well post it.

I'm trying to build an x86 -> x86_64 cross toolchain
with binutils-2.14.90.0.5, gcc-3.3.2, and glibc-2.3.2.

Here's how I build it:

wget http://kegel.com/crosstool/crosstool-0.26-pre1.tar.gz
tar -xzvf crosstool-0.26-pre1.tar.gz
cd crosstool-0.26-pre1
sh demo-x86_64.sh

(You can see the script and the patches I use without unpacking, if you like:
http://kegel.com/crosstool/crosstool-0.26-pre1/demo-x86_64.sh.txt
http://kegel.com/crosstool/crosstool-0.26-pre1/crosstool.sh.txt
http://kegel.com/crosstool/crosstool-0.26-pre1/gcc-3.3.2-glibc-2.3.2.dat
http://kegel.com/crosstool/crosstool-0.26-pre1/x86_64.dat
http://kegel.com/crosstool/crosstool-0.26-pre1/patches/ )

The build fails during the build of the final gcc's target libiberty with the error:

checking whether the C compiler ( /home/dkegel/wk/crosstool-0.26-pre1/build/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/build-gcc/gcc/xgcc -B/home/dkegel/wk/crosstool-0.26-pre1/build/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/build-gcc/gcc/ -B/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/x86_64-unknown-linux-gnu/bin/ -B/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/x86_64-unknown-linux-gnu/lib/ -isystem /opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/x86_64-unknown-linux-gnu/include -O2 -g -O2 ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.
make: *** [configure-target-libiberty] Error 1


http://www.x86-64.org/lists/bugs/msg00865.html also
mentions this problem, but doesn't have a solution.

So configure can't link a trivial program.  I tried
compiling a trivial program by hand with that same command,
and sure enough, got an error:

/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/x86_64-unknown-linux-gnu/bin/ld: warning: ld-linux-x86-64.so.2, needed by /opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64/libc.so.6, not found (try using -rpath or -rpath-link)
/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64/libc.so.6: undefined reference to `_dl_lookup_versioned_symbol_skip@GLIBC_PRIVATE'
...


But the file ld-linux-x86-64.so.2 does exist; it's at
/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/x86_64-unknown-linux-gnu/lib64/ld-linux-x86-64.so.2

so maybe the linker got invoked with the wrong options.
To find out what options were passed to the linker, I replaced the
linker with a shell script that prints out its args,
then invokes the real linker.  Here's what that showed:

.../ld --eh-frame-hdr -m \
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 \
/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64/crt1.o \
/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64/crti.o \
/home/dkegel/wk/crosstool-0.26-pre1/build/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/build-gcc/gcc/crtbegin.o \
-L/home/dkegel/wk/crosstool-0.26-pre1/build/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/build-gcc/gcc \
-L/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/x86_64-unknown-linux-gnu/bin \
-L/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/x86_64-unknown-linux-gnu/lib \
-L/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2 \
-L/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64 \
-L/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib \
x.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh \
/home/dkegel/wk/crosstool-0.26-pre1/build/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/build-gcc/gcc/crtend.o
/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64/crtn.o \

ld-linux-x86-64.so.2 can be found via the longest of the -L args to the linker:

$ ls -lL /opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64/ld-linux-x86-64.so.2
-rwxr-xr-x    1 dkegel   eng         98620 Jan  6 17:22 /opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64/ld-linux-x86-64.so.2

so I guess ld doesn't obey -L for that file?!
Sure enough, gld${EMULATION_NAME}_after_open(void) in ld/emultempl/elf32.em
says
      /* We need to find this file and include the symbol table.  We
         want to search for the file in the same way that the dynamic
         linker will search.  That means that we want to use
         rpath_link, rpath, then the environment variable
         LD_LIBRARY_PATH (native only), then the DT_RPATH/DT_RUNPATH
         entries (native only), then the linker script LIB_SEARCH_DIRS.
         We do not search using the -L arguments.

All right... so I ran that ld with --verbose, and the linker script contained just
one SEARCH_DIR:
SEARCH_DIR("/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3.2-glibc-2.3.2/x86_64-unknown-linux-gnu/lib");

Googling for "lib64 SEARCH_DIR" came up with that message in the binutils
list that said --with-sysroot is the right way.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]