This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
shouldn't dlopen() resolve library paths the same as ld.so?
- To: libc-alpha at sourceware dot cygnus dot com
- Subject: shouldn't dlopen() resolve library paths the same as ld.so?
- From: Ben Collins <bcollins at debian dot org>
- Date: Sun, 3 Dec 2000 14:41:39 -0500
I'm having some difficulty with programs that use are using dlopen() to
open system libraries. Basically I have this setup:
/lib/libc.so.6
/lib/i686/libc.so.6
Where the i686 directory contains i686 optimized libraries (in this case,
just glibc libs). If a program is linked to libpthread, when it starts up,
ld.so loads /lib/i686/libpthread.so.0. Then later this same program calls
this:
dlopen("libpthread.so.0", RTLD_LAZY);
which actually loads /lib/libpthread.so.0. Is this the correct behavior?
Shouldn't it resolve the path the same as ld.so does? This mainly causes
problems only because the optimized libpthread is compiled with
--enable-omitfp, so I can understand the conflict of loading both
libraries at once. I'm just concerned about two different library
resolving functionalities in this case.
Ben
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'