This is the mail archive of the
mailing list for the binutils project.
Re: PLT entry not initialized when loading a library, but called nevertheless
- From: Igor Pashev <pashev dot igor at gmail dot com>
- To: binutils at sourceware dot org
- Cc: sergey dot prokhorenko at gmail dot com
- Date: Tue, 11 Dec 2012 19:41:20 +0400
- Subject: Re: PLT entry not initialized when loading a library, but called nevertheless
- References: <50C7400B.firstname.lastname@example.org>
11.12.2012 18:15, Sergey Prokhorenko ÐÐÑÐÑ:
> 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:
> I ran app with LD_DEBUG=bindings and found out that libC can't find a
> 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.
This is hardly a binutils bug, especially on linux/x86_64 :-)
I can guess, that libC is not linked to libgomp (from GCC) or whichever
OpenMP library being used.