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

[Andreas Jaeger <aj at suse dot de>]

>>>>> Ben Collins writes:

 > 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.

Please check with LD_DEBUG=libs (or files) the search paths and send
the output.  It should work the same, the difference might be ldconfig
- ldconfig couldn't handle i686 in plain 2.2, I had to add a patch to
fix this.  Therefore try it also after removing /etc/ld.so.cache.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj