This is the mail archive of the 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)
suggests that the only way to build a 32 -> 64 bit cross toolchain
is to use --with-sysroot! 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, ?

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-, gcc-3.3.2, and glibc-2.3.2.

Here's how I build it:

tar -xzvf crosstool-0.26-pre1.tar.gz
cd crosstool-0.26-pre1

(You can see the script and the patches I use without unpacking, if you like: )

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 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:, 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/, 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/ undefined reference to `_dl_lookup_versioned_symbol_skip@GLIBC_PRIVATE'

But the file does exist; it's at

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/ \
/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 \
/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 \ 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/
-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/

so I guess ld doesn't obey -L for that file?!
Sure enough, gld${EMULATION_NAME}_after_open(void) in ld/emultempl/elf32.em
      /* 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

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]