Restricting symbols from getting exported to global symb table
in [Unix Programming]
|
Prev: unformatted file
Next: a tricky expression
From: anirudh on 26 Nov 2009 11:14 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
From: WANG Cong on 27 Nov 2009 09:13 On 11/27/09 00:14, anirudh <ani.purkar(a)gmail.com> wrote: > 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? I am not sure if I understand your situation, does '-fvisibility' of gcc help? -- Live like a child, think like the god.
From: anirudh on 27 Nov 2009 10:20 On Nov 27, 7:13 pm, WANG Cong <xiyou.wangc...(a)gmail.com> wrote: > On 11/27/09 00:14, anirudh <ani.pur...(a)gmail.com> wrote: > > > > > 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? > > I am not sure if I understand your situation, does > '-fvisibility' of gcc help? > > -- > Live like a child, think like the god. 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.
From: Rainer Weikusat on 27 Nov 2009 10:46 anirudh <ani.purkar(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.
From: anirudh on 27 Nov 2009 13:42
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. |