From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30486 invoked by alias); 9 Jan 2013 00:50:29 -0000 Received: (qmail 30324 invoked by uid 48); 9 Jan 2013 00:49:54 -0000 From: "lfs4pi at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/15006] New: Libraries in ld.so.cache ignored by ld-linux-armhf.so.3 on armv6l Date: Wed, 09 Jan 2013 00:50:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: lfs4pi at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00033.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15006 Bug #: 15006 Summary: Libraries in ld.so.cache ignored by ld-linux-armhf.so.3 on armv6l Product: glibc Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: dynamic-link AssignedTo: unassigned@sourceware.org ReportedBy: lfs4pi@gmail.com Classification: Unclassified I build Linux From Scratch systems for the Raspberry Pi and completed a new build where glibc 2.16 has been replaced by glibc 2.17. The system runs great in general except for a peculiar behavior of the dynamic runtime linker to ignore needed libraries, in non-standard locations, that are clearly in ld.so.cache. As an example I will try to execute a binary that depends on two libraries, that I compiled myself, located in /opt/vc/lib: [root@0] [/] cd /opt/vc/bin [root@0] [/opt/vc/bin] ./vcgencmd measure_temp ./vcgencmd: error while loading shared libraries: libvcos.so: cannot open shared object file: No such file or directory Let's verify with ldd: [root@0] [/opt/vc/bin] ldd vcgencmd libvcos.so => not found libvchiq_arm.so => not found libpthread.so.0 => /lib/libpthread.so.0 (0xb6f4f000) libdl.so.2 => /lib/libdl.so.2 (0xb6f44000) librt.so.1 => /lib/librt.so.1 (0xb6f35000) libc.so.6 => /lib/libc.so.6 (0xb6e03000) /lib/ld-linux-armhf.so.3 (0xb6f6e000) But it's in the cache! [root@0] [/opt/vc/bin] cat /etc/ld.so.conf /opt/vc/lib [root@0] [/opt/vc/bin] rm /etc/ld.so.cache [root@0] [/opt/vc/bin] ldconfig -v | grep vcos libvcos.so -> libvcos.so [root@0] [/opt/vc/bin] ldconfig -p | grep vcos libvcos.so (libc6) => /opt/vc/lib/libvcos.so Using LD_LIBRARY_PATH, it works: [root@0] [/opt/vc/bin] LD_LIBRARY_PATH=/opt/vc/lib ./vcgencmd measure_temp temp=50.8'C A debug output, where it at least seems to look at ld.so.cache: [root@0] [/opt/vc/bin] LD_DEBUG=libs ./vcgencmd 522: find library=libvcos.so [0]; searching 522: search cache=/etc/ld.so.cache 522: search path=/lib/tls/v6l/vfp:/lib/tls/v6l:/lib/tls/vfp:/lib/tls:/lib/v6l/vfp:/lib/v6l:/lib/vfp:/lib:/usr/lib/tls/v6l/vfp:/usr/lib/tls/v6l:/usr/lib/tls/vfp:/usr/lib/tls:/usr/lib/v6l/vfp:/usr/lib/v6l:/usr/lib/vfp:/usr/lib (system search path) 522: trying file=/lib/tls/v6l/vfp/libvcos.so 522: trying file=/lib/tls/v6l/libvcos.so 522: trying file=/lib/tls/vfp/libvcos.so 522: trying file=/lib/tls/libvcos.so 522: trying file=/lib/v6l/vfp/libvcos.so 522: trying file=/lib/v6l/libvcos.so 522: trying file=/lib/vfp/libvcos.so 522: trying file=/lib/libvcos.so 522: trying file=/usr/lib/tls/v6l/vfp/libvcos.so 522: trying file=/usr/lib/tls/v6l/libvcos.so 522: trying file=/usr/lib/tls/vfp/libvcos.so 522: trying file=/usr/lib/tls/libvcos.so 522: trying file=/usr/lib/v6l/vfp/libvcos.so 522: trying file=/usr/lib/v6l/libvcos.so 522: trying file=/usr/lib/vfp/libvcos.so 522: trying file=/usr/lib/libvcos.so 522: ./vcgencmd: error while loading shared libraries: libvcos.so: cannot open shared object file: No such file or directory I don't have the time and probably not the skills necessary for a lengthy gdb session, but if I had to guess I'd point to the recent changes in ports/sysdeps/unix/sysv/linux/arm as a possible clue. Apart from ld-linux-armhf.so.3, there's also a ld-linux.so.3 compatibility symlink. Not sure if that could play a part in this. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.