Prev: unformatted file
Next: a tricky expression
From: param on 27 Nov 2009 14:51
I hope your problem something like:
fun1() -> fun1.a
fun1() [new version of fun1] -> fun2.a
third party shared library links with fun2.a -> libfun2.so
your executable links with both fun1.a and libfun2.so -> abc
So, when abc gets loaded into memory, it would have two definition for
fun1 in memory, but when the member functions of
the shared library make calls to fun1, it always refer/invoke the
first definition of the fun1.

If that is your problem, linker option "--exclude-libs <<list of
archives>>" would help you to solve the problem. It stops the linker
to export the symbols from archive.









From: Rainer Weikusat on 27 Nov 2009 16:46
anirudh <ani.purkar(a)gmail.com> writes:
> On Nov 27, 8:46�pm, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>> anirudh <ani.pur...(a)gmail.com> writes:
>>
>> [...]
>>
>> > Actually I have an executable which is statically liked to a �third
>> > party library say "ver1.a" and also uses a third party ".so" �file
>> > which is again linked with same �library but different version say
>> > "ver2.a". Problem is implementation of both these versions is
>> > different. At the beginning, when executable is loaded, symbols from
>> > "ver1.a" will get exported to global symbol table. Now whenever ".so"
>> > is loaded it will try to refer to symbols from ver2.a, it will end up
>> > referring to symbols from "ver1.a" which were previously loaded.Thus
>> > crashing our binary.
>>
>> This doesn't make sense. Linking with an ar-archive happens completely
>> at link time: The referenced archive members are copied into the
>> binary and their addresses are resolved statically. There is no
>> runtime symbol lookup.
>
> Hi Rainer,
> But here we have two components..
> a) an executable binary with symbols from ver1.a
> b) a third party .so with symbols from ver2.a.
> This third party .so file is dynamically linked with the executable.

If the so-file has been statically linked with an ordinary ar-archive,
as your statement suggests (the ver2.a-file) then it won't to any
symbol lookups at runtime for anything which was contained in ver2.a
because the references will have been resolved at link time. That's
why it is called 'statically linked'. If there is a symbol conflict,
that must come from two different versions of something with one
version being linked dynamically to the .so-file and the other
dynamically to the executable (or the executable purposely providing a
particular 'dynamic symbol' which replaces one which would otherwise
have been found in one of the libraries the .so-file was linked with).

Maybe helpful: A list of 'dynamic symbols', both provided and required
by some file, can be displayed with nm -D <filename>.
First  |  Prev  | 
Pages: 1 2
Prev: unformatted file
Next: a tricky expression