Fwd: Multiarch Cross-toolchains : "-rpath-link" mandatory ?

Shawn Landden, using iOS

Begin forwarded message:

> From: Shawn Landden <[email protected]>
> Date: October 4, 2012 8:37:23 AM MDT
> To: Sébastien NOEL <[email protected]>
> Subject: Re: Multiarch Cross-toolchains : "-rpath-link" mandatory ?
> 

> This problem was fixed in Ubuntu.
> 
> On Oct 4, 2012, at 7:31 AM, Sébastien NOEL <[email protected]> wrote:
> 
>> Hi,
>> 
>> After reading the "Debian's Google Summer of Code 2012 wrap-up"
>> on debian-devel-announce, i did want to test a Multiarch
>> Cross-toolchains, so i did rebuild gcc with patches
>> from http://emdebian.org/~thibg/patches/gcc-4.7/
>> and it almost works :-)
>> 
>> But i'm wondering if i did something wrong, because i can't
>> trivially link with other libs :(
>> 
>> ~/trivial-test# cat 1.c
>> #include <stdio.h>
>> int main(void)
>> {
>> printf("Hello world\n");
>> return 0;
>> }
>> 
>> a simple "arm-linux-gnueabihf-gcc 1.c" works perfectly,
>> but...
>> 
>> # arm-linux-gnueabihf-gcc 1.c -lasound
>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/../../../../arm-linux-gnueabihf/bin/ld: warning: libm.so.6, needed by /usr/lib/arm-linux-gnueabihf/libasound.so, not found (try using -rpath or -rpath-link)
>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/../../../../arm-linux-gnueabihf/bin/ld: warning: libdl.so.2, needed by /usr/lib/arm-linux-gnueabihf/libasound.so, not found (try using -rpath or -rpath-link)
>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/../../../../arm-linux-gnueabihf/bin/ld: warning: libpthread.so.0, needed by /usr/lib/arm-linux-gnueabihf/libasound.so, not found (try using -rpath or -rpath-link)
>> /usr/lib/gcc/arm-linux-gnueabihf/4.7/../../../../arm-linux-gnueabihf/bin/ld: warning: librt.so.1, needed by /usr/lib/arm-linux-gnueabihf/libasound.so, not found (try using -rpath or -rpath-link)
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `clock_gettime@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `log@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `pthread_join@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `fmod@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `ceil@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `rintf@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `floor@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `dladdr@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `pthread_mutex_trylock@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `sqrtf@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `exp@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `sqrt@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `pow@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `dlsym@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `dlclose@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `log10@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `pthread_create@GLIBC_2.4'
>> /usr/lib/arm-linux-gnueabihf/libasound.so: undefined reference to `dlopen@GLIBC_2.4'
>> collect2: error: ld returned 1 exit status
> 
> Correct ld does direct linking fine, the problem is indirect linking. I mention the bug # on LP in the changelog of kyotocabinet pkg in git.(alioth) It is also mentioned throughout the wiki. Debian really needs to fix this problem (and also a similar and much more trivial (but important) issue in pkg-config-cross. 
>> 
>> if i add 1) all the needed libs ; or 2) "-rpath-link"
>> it works.
>> 
>> # arm-linux-gnueabihf-gcc 1.c -lasound -lm -lpthread -ldl -lrt
>> # arm-linux-gnueabihf-gcc 1.c -lasound -Wl,-rpath-link=/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf
>> 
>> so, my questions are:
>> - is it normal ?
>> - if it's the expected behavior, is there any environment variables
>> that need to be set to tell gcc where to find the libs ?
>> - did i miss something else ?
>> 
>> Thanks,
>> 
>> Sébastien