This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


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

shouldn't dlopen() resolve library paths the same as ld.so?


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  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

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