This is the mail archive of the 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]
Other format: [Raw text]

Re: PLT entry not initialized when loading a library, but callednevertheless

On 12.12.2012 02:09, Mike Frysinger wrote:
On Tuesday 11 December 2012 13:23:22 Sergey Prokhorenko wrote:
So my question is (if you allow as I'm not really big expert in this
are) - can it be that this is dlopen/ld bug and am I in the correct
mail list after all? I think now that it is not ld bug, it seems that
ld stops loading but dl continues despite the error.
you might be seeing lazy relocation.  do you get different behavior if you
export LD_BIND_NOW=1 ?
It makes no difference. I tried with it and LD_DEBUG=all and here's what I see in log after the omp_ symbol is not found for libC:

19225: symbol=omp_set_num_threads; lookup in file=/usr/lib/i386-linux-gnu/ [0]
19225: /media/EXT/Work/ error: symbol lookup error: undefined symbol: omp_set_num_threads (fatal)
19225: file=/media/EXT/ [0]; destroying link map
19225: file=/media/EXT/ [0]; dynamically loaded by /media/EXT/ [0]
19225: file=/media/EXT/ [0]; generating link map
19225: dynamic: 0xf2fdb764 base: 0xf2f81000 size: 0x00064a28
19225: entry: 0xf2f8ffd0 phdr: 0xf2f81034 phnum: 7
19225: checking for version `GCC_3.0' in file /lib/i386-linux-gnu/ [0] required by file /media/EXT/ [0]
... few more checking
19225: object=/media/EXT/ [0]
19225: scope 0: bin/mainapp /lib/i386-linux-gnu/ /media/EXT/ ...
19225: scope 1:...
19225: relocation processing: /media/EXT/
19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=bin/mainapp [0]
19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=/lib/i386-linux-gnu/ [0]
19225: symbol=_ZTVN10__cxxabiv117__class_type_infoE; lookup in file=/media/EXT/ [0]
19225: binding file /media/EXT/ [0] to /media/EXT/ [0]: normal symbol `_ZTVN10__cxxabiv117__class_type_infoE'

... here it continues to bind libA symbols, and after finishing that

19225: calling init: /media/EXT/

it calls init for the non-initialized module.

(Just to mention is the base module that calls dlopen and also contains basic methods used by all other libs.)

After destroying link map for libA the log shows that it is generated again, I just don't understand if loader continues to load libA or starts from scratch this time without bothering about libB/libC. Well, it ignores libB/libC in any case until init is calledfor libC.

Thanks, Sergey.

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