This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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]

[MIPS, n32, glibc 2.9] ld.so.cache problem.


I'm seeing the behavior of ld.so apparently
not being able to use the contents of /etc/ld.so.cache.

I have some applications that have shared libraries under
/opt.  The shared library path appears in /etc/ld.so.conf,
and when ldconfig is run in a verbose mode, it reports
that it is finding all these libraries under /opt and
entering them into the cache.

Moreover, the cache image contains the names of these
libraries and their paths as character strings.

However, when the programs are run, they are not able
to find their libraries.

I tried running them with LD_DEBUG=all, and strace also,
but there is nothing useful. The dynamic linker opens
the cache, mmaps it and then closes the file descriptor.
It reports that it's using the cache, but that's it;
there are no further details about anything being done
using the cache. The linker can't find the libraries
in any of the standard locations, like /lib32 and so on,
and gives up.

If the /opt/... path from /etc/ld.so.conf is set up as
LD_LIBRARY_PATH, then these programs are able to find
their libraries.

Anyone else seeing this broken cache behavior?


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