PLT entry not initialized when loading a library, but called nevertheless

[Sergey Prokhorenko <sergey dot prokhorenko at gmail dot com>]

Hello.

Sorry to bother if that's not an appropriate mailing list but I'm not 
really sure where to postthis question about ld and shared library loading.

I found a strange bug when loading a nested shared library. Say I have 
libA that depends on libB that depends on libC. A/B I compile myself and 
C is precompiled in binary form by 3rd party (not that it's really 
important but).

When I start the appit crashes with SIGSEGV 
after__static_initialization_and_destruction_0in libC, while calling 
MyFunc@plt from my "common to all" library libX. The stack is as follows:

0x12345
__static_initialization_and_destruction_0
...
dlopen("libA")

I ran app with LD_DEBUG=bindings and found out that libC can't find a 
symbol:
     10272: /media/EXT/work//libC.so: error: symbol lookup error: 
undefined symbol: omp_set_num_threads (fatal)

which is probably the 3rd-party libC problemBUT after that, it continues 
to resolve symbols inside libA while completely skipping the rest of 
libC and all of the libB ones. So that when it comes to calling static 
initof libC then half of PLT entries are unresolved, thus the crash. Or 
that's how I see it.

I have built anoptimized version of my app and there for some reason it 
is able to resolve that symbol (to libgomp). Also I see there that 
without unresolved omp_ error it completes libC bindings then continues 
with libB bindings and then with libA bindings. This is to compare to 
the non-optimized version (as described above) where it does not 
complete libC bindings and does not do libB.

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 bugand am I in the correct mail list 
after all?

The environment is Ubuntu 12.04 x86_64 with latest updates, app is i386 
though, compiled with stock gcc 4.6. Iam not sure where and how libC was 
compiled.Since everything worked fine when compilingon Ubuntu 11.10 I 
may suspect that libC was also compiled here, and the bug appeared when 
we upgraded to Ubuntu 12.04 and its gcc/ld.The bug was gone when I get 
updated libC version built on 12.04 from3rd party. Still I wonder why 
itis possible to leave shared library (even built by some other tool) in 
a half-initialized state andare my conclusions above correct.

Thanks, Sergey.