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
