Restricting symbols from getting exported to global symb table

[anirudh]

Hi All,

We have an executable on Linux which is linked to some third party
library. When our executable gets loaded , we got symbol conflicts for
the third party shared library.
To resolve the symbol conflict we tried to build our executable with
'--version-script' to restrict the symbols to local scope , however we
found that symbols were still getting exported to global symbol table.

After looking at some mailing list we found that the --version-script
option works only with Shared library and not with executable on Linux
platform.

We tried another linker flag 'retain-symbol-file’ which is applicable
to even executable s that prevents symbols being added to global
symbol table. With this option, we could see that only listed symbols
in the file were shown in the ‘nm’ output but still we see symbol
conflict when executable gets loaded.

Can anyone please suggest some way we can restrict exporting of our
symbols to global symbol table?

Thanks in advance

[WANG Cong]

I am not sure if I understand your situation, does
'-fvisibility' of gcc help?

--
Live like a child, think like the god.

[anirudh]

On Nov 27, 7:13 pm, WANG Cong <xiyou.wangc...@gmail.com> wrote:

Hi,

Thanks for replying...

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.

we thought of a solution that we wont be exporting the symbols for
executable to Global symbol table, thus when ".so" gets loaded and
will try to use symbols from ver2.a it wont find it in global symbol
table and it will use its own symbols i.e symbols from ver2.a

I cant find any way by which i can restrict exporting of symbols to
global symbol table. I tried with --version-script and retain-symbol-
file, but it didn't work. For -fvisibility, its giving an error that "
-f option may only be used with -shared". So I guess, this too like "--
version-script" works only for shared libraries and not for executable
binaries.

code is in c++, gcc version-3.2. It may not be possible to recompile
any of the third party libraries and ".so"s.
Any help would be appreciated.

[Rainer Weikusat]

anirudh <ani.p...@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.

[anirudh]

On Nov 27, 8:46 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

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.

[param]

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.

[Rainer Weikusat]

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