Building self contained GNU toolchains
NOTE: This page is being worked on.
* Built to provide binutils for gcc, current uses the system loader /lib/ld.so
* Must have hacked dynamic-linker setting to point to the new loader so that the next binutils build will have the correct loader path.
* Built with the new gcc and provide a base level of libraries
glibc64 binutils gcc glibc32 glibc64
* Built to pick up the correct loader path.
Linker vs. Loader
The static linker (i.e. ld provided by binutils) is invoked when applications are compiled and linked, e.g.
gcc test.c -o test -lm
In this example libm is indicated in the link. Linkage provides three things, Library name, version, and symbols.
The dynamic linker/loader (i.e. ld.so provided by glibc) is invoked when an application is executed, e.g.
At this stage the AT_PLATFORM is checked for the architecture specific cpu and the loader looks for a library which matches, e.g.
/lib/power5/libm.so is found before /lib/libm.so on Power5 hardware.
At this point ld.so loads the necessary libraries and finishes dynamic relocations any remaining symbols that couldn't be relocated at compile time.
Debugging applications which don't use the standard loader
Invoke gdb against the loader that you've built and invoke
gdb64 -x /work/usr/src/build-23/rpcgen.gdb -cd=/work/usr/src/libc23/sunrpc /work/usr/src/build-23/elf/ld64.so.1
set environment CPP gcc64t -E -x c-header b *0x080158f4 b *0x08015ac8 b *0x080059e8 run --library-path /work/usr/src/build-23:/work/usr/src/build-23/math:/work/usr/src/build-23/elf:/work/usr/src/build-23/dlfcn: /work/usr/src/build-23/nss:/work/usr/src/build-23/nis:/work/usr/src/build-23/rt:/work/usr/src/build-23/resolv: /work/usr/src/build-23/crypt:/work/usr/src/build-23/linuxthreads /work/usr/src/build-23/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /work/usr/src/build-23/sunrpc/xbootparam_prot.T --direct
Note: the --direct flag is required because the GLIBC make check test-skeleton takes the --direct flag as an indication to not fork a process for the particular test but to rather run it inline.
Getting the loaded library offsets in GDB
Use the gdb command 'info shared' to determine at which offsets the dynamically linked libraries are loaded.
Breakpoint 1, 0x100005a4 in main () (gdb) info shared From To Syms Read Shared Object Library 0xf7fe1280 0xf7ffa830 Yes /opt/at05/lib/ld.so.1 0x0ffa3660 0x0ffd1670 Yes /opt/at05/lib/libdfp.so 0x0fe2e3c0 0x0ff4c0b0 Yes /opt/at05/lib/libc.so.6 0x0fd52ee0 0x0fda4490 Yes /opt/at05/lib/libm.so.6 (gdb)
Q. My self contained toolchain's `as' or `ld' doesn't find the right libc. Notice how /opt/biarch/tc/bin/as doesn't find /opt/biarch/tc/lib/tls/libc.so.6 but finds the system toolchain instead? What is going on?
LD_DEBUG=libs /opt/biarch/tc/bin/as 622: find library=libc.so.6 ; searching 622: search cache=/etc/ld.so.cache 622: trying file=/lib/tls/libc.so.6
A. You need to make sure that you've modified /opt/biarch/tc/etc/ld.so.conf and rerun /opt/biarch/tc/sbin/ldconfig.
Q. I've built a toolchain into /opt/biarch/<some_location>/ but when I try to run an application I get the following error. Why?
usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../powerpc-suse-linux/bin/ld: /home/ryanarn/packages/build/glibc32_dfp/csu/crti.o: unknown relocation type 250 for symbol _GLOBAL_OFFSET_TABLE_
A. One of two things has happened.
- Your environment has lost the PATH to your speciality toolchain and you'll need to re-export your path.
- You're missing a step in your toolchain build process. Was 'ld' built with a gcc which specified the /opt/biarch toolchain location?
Note: Relocation type 250 for symbol _GLOBAL_OFFSET_TABLE_ is a PIC relocation type for 'secure-plt'.
Please see the compatibility matrix wiki page.