This is the mail archive of the binutils@sourceware.org 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]

Recursive library linkage behaviour


(Please keep me cc:ed, I'm not on this list)

This bug:
https://bugs.launchpad.net/ubuntu/+source/armel-cross-toolchain-base/+bug/923779

has caused me to try and understand some things about how linking
actually works.

There is a simple test script to illustrate the problem here:
https://bugs.launchpad.net/ubuntu/+source/armel-cross-toolchain-base/+bug/923779/+attachment/2701364/+files/test-toolchain.sh

rm -f /usr/lib/arm-linux-gnueabi/lib{lo,hi}.so
cat > liblo.c <<EOF
int alowcall(int a,int b) {return a+b;}
EOF

cat > libhi.c <<EOF
int alowcall(int a,int b);
int ahicall(int a) {return alowcall(a,-a);}
EOF

cat > hiuser.c <<EOF
int ahicall(int a);
int main(void) {return ahicall(27);}
EOF

arm-linux-gnueabi-gcc -fPIC liblo.c -shared -o liblo.so
arm-linux-gnueabi-gcc -fPIC libhi.c -shared -o libhi.so -L. -llo
cp liblo.so libhi.so /usr/lib/arm-linux-gnueabi/
arm-linux-gnueabi-gcc hiuser.c -lhi -o foouser

-----------

It is about the case where a binary (main) uses a symbol in a library (libhi
in the test script). And libhi uses a symbol in liblo. But main does
not directly reference liblo.

Now the bug is about how the cross case differs from the native case
when linking. The directly-referenced library libhi is always found no
problem, and in the native case the indirectly-refernced liblo is also
found, but in the cross case it wasn't, which turned out to be because
the default linker script didn't have the right library path in
SEARCH_DIR.

That is easily fixed by putting the right path into the default linker
script SEARCH_DIR list.

However, the thing I don't understand is why does the linker needs to
find liblo at all? liblo is not a build-dependency of main; only libhi
is. liblo is a build-dep of libhi and is obviously needed when libhi
is built. Is it correct that in fact the linker should be recursing
through the symbol tree in this way?

Now in fact liblo will always be present, because it is an
install-time dependency of libhi, so this recursion should always
work. It's just that my naive understanding of what goes on is that
(when building for dynamic linking) only the directly referenced
symbols in libraries are looked-up, symbols in liblo are only
looked-up when libhi is built, and then everything is resolved at
load-time when main is actually run. Am I just wrong/confused about
this?

Thank you for any clarification you can provide. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


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