[uClibc] linking issues with libraries in non-standard paths

Mike Frysinger vapier at gentoo.org
Sat Aug 28 01:04:55 UTC 2004


i've been banging my head on this for sometime and been unable to make any 
progress ... hopefully someone can point out something stupid that i 
missed :)

note that with the following example, i *know* libgcc_s.so.1 is a critical app 
and should in all normal circumstances, live in /lib/ ... the example is 
prove a point (broken linking)

i have two arm boxes; one runs glibc, the other uclibc ...
both boxes have:
 - libncurses.so linked against libgcc_s.so.1
 - gcc version 3.3.4
 - binutils version 2.14.90.0.{6,7}
 - libgcc_s.so.1 in /usr/lib/gcc-lib/<host>/3.3.4/
 - ld.so.conf points to the above lib location and ld.so.cache is updated
i have cache support turned on in uclibc so ld.so.cache supports the fact i 
have libgcc_s.so.1 in such a weird place ... uclibc is from latest cvs and so 
it has all the cache work eric has done and the few patches i added to finish 
it up ...

testing with ldd doesnt register the fact libgcc_s.so.1 is in this 
non-standard dir because ldd doesnt yet support ld.so.cache (known problem 
according to comments in ldd.c); the runtime linker does however ... to prove 
this, all apps that need libgcc_s.so.1 (like ls and ps for example) work 
fine ... and all ncurses based apps work fine (like nano and less) ...

the problem comes in when i try to link against libncurses:
glibc ~ # gcc test.c -lncurses
glibc ~ # ./a.out
hello
uclibc ~ # gcc test.c -lncurses
/usr/lib/gcc-lib/arm-pc-linux-uclibc/3.3.4/../../../../arm-pc-linux-uclibc/bin/ld: 
warning: libgcc_s.so.1, needed by /lib/libncurses.so, not found (try using 
-rpath or -rpath-link)
/lib/libncurses.so: undefined reference to `__modsi3 at GCC_3.0'
/lib/libncurses.so: undefined reference to `__udivsi3 at GCC_3.0'
/lib/libncurses.so: undefined reference to `__divsi3 at GCC_3.0'
/lib/libncurses.so: undefined reference to `__umodsi3 at GCC_3.0'
collect2: ld returned 1 exit status

so my question is, why am i seeing this discrepancy ?  ld has no problem 
locating my oddly place library when run in the glibc environment, yet barfs 
all over itself inside my uclibc environment :(
-mike


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 838 bytes
Desc: signature
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20040827/defa7673/attachment-0002.pgp 


More information about the uClibc mailing list