views:

81

answers:

3

Hi,

I have created a .c file which is being converted to a .o file along with around 300 other .c files and included in a .a static library. This library, along with many others is being used to create a .so dynamic library. On analyzing both the .a and the .so file with nm, I found that for some reason the symbols defined in the .c file are present in the .a file but not in the .so file. I can think of no reason this should happen. Can somebody please help me out here? The steps used to create the two binaries are:

gcc -fvisibility=hidden -c foo.c -o foo.c.o
ar cr libbar.a foo.c.o ...
gcc -fvisibility=hidden -fPIC -o libfinal.so libbar.a x.o y.a ... 

The reason I have specified visibility hidden here is that I want to expose only a few selected symbols. To expose the symbols from foo.c I have specified the visibility attribute so that the functions signatures in the header foo.h look like:

extern int __attribute__ ((visibility ("default"))) func();

EDIT: The command nm libbar.a | grep Ctx gives:

000023c5 T CtxAcquireBitmap
000026e9 T CtxAcquireArray
00001e77 T CtxCallMethod

However, nm libfinal.so | grep Ctx does not show anything.

UPDATE: Found another post which discusses the uses of the --whole-archive option. Also, stumbled across the --export-dynamicoption which apparently tells the linker to retain unreferenced symbols. Investigating further.

+2  A: 

Try using --whole-archive linker option to include all objects into your shared library when linking

gcc -o libfinal.so -Wl,--whole-archive libbar.a x.o y.a -Wl,--no-whole-archive

From man ld:

--whole-archive
For each archive mentioned on the command line after the --whole-archive option, include every object file in the archive in the link, rather than searching the archive for the required object files. This is normally used to turn an archive file into a shared library, forcing every object to be included in the resulting shared library. This option may be used more than once.

Two notes when using this option from gcc: First, gcc doesn't know about this option, so you have to use -Wl,-whole-archive. Second, don't forget to use -Wl,-no-whole-archive after your list of archives, because gcc will add its own list of archives to your link and you may not want this flag to affect those as well.

Dmitry Yudakov
Hmm. Good point. Enclosing this `.a` within the two tags is going to be complicated though as my project uses `CMake`. Have to think of a way to do it within project constraints. Thanks.
Rajorshi
try this: http://www.mail-archive.com/[email protected]/msg01890.html
Dmitry Yudakov
sylvainulg
including just this static library between --whole-archive and --no-whole-archive should be safe, no need to include standard libraries
Dmitry Yudakov
+1  A: 

As far as I know, when compiling against a .a, gcc will only pull out the objects that are referenced by the other modules. If your intent is to include the whole content of the .a in the .so, a plain "compile/link x.c into libfinal.so using content in libbar.a" is not what you want.

sylvainulg
Yes, this is it. From the gcc 4.3.2 man page on my system - "The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion."
Troubadour
I'd be tempted to say that the most common approach to produce the .a and the .so is to build them both from a collection of .o files, not to build one out of the other one.
sylvainulg
A: 

Creating a dummy reference for the required symbols in my main file did not solve the problem. The referenced symbols appeared in the binary dump (obtained using nm) with a U (= undefined) marker. I managed to solve the problem by linking the object file directly when creating the .so file instead of including it in the .a library first. As these functions were marked extern they were included in the .so even though they were not being referenced within the library. Had they not been marked extern, they would not have been included just like sylvainulg said.

Thanks to Dmitry for pointing out the --whole-archive option. I did not know that such an option exists.

Rajorshi