1

For a project we are trying to create a shared object file that exports a set of functions specified in libname.exports. Of course we know that the object files from which the .so file gets linked have to be created using -fPIC, so that has been taken care of. We then combined the object files into an archive named libname.a. This should now be the basis for the .so file to be created - or so was the idea.

We're passing libname.exports to --retain-symbols-file, so the expected behavior was that the linker would pull in any of the .a members relevant to those symbols.

However, the output of nm libname.so is empty. On the other hand grepping in nm libname.a shows that the relevant symbols named in libname.exports exist in the .a members.

Now I stumbled over --whole-archive and thus adjusted the command line from:

gcc -o libname.so -shared -Wl,-z,defs,--retain-symbols-file,libname.exports,-L. libname.a -lc

to:

gcc -o libname.so -shared -Wl,-z,defs,--retain-symbols-file,libname.exports,-L.,--whole-archive,libname.a,--no-whole-archive -lc

which appears to have the intended effect of including all the object files from the .a (although the size difference is strange). However, nm libname.so still gives me no output.

How can I use the archive file to create a shared object with only the symbols named in libname.exports visible?

Unfortunately How to create a shared object file from static library doesn't quite answer my question.

Note: before you ask. The idea behind using the .a file as input is because it makes it easy to use a pattern rule in GNUmakefile and because the .a file with -fPIC is needed regardless. There shouldn't be any difference between linking the individual object files versus the archive file.

Community
  • 1
  • 1
0xC0000022L
  • 20,597
  • 9
  • 86
  • 152
  • Have you _tried_ extracting and linking the separate object files? – Some programmer dude Sep 26 '12 at 12:15
  • @Joachim Pileborg: yes. That works as long as the `libname.exports` contains the symbol names to be exported and `libname.a` contains the respective members. What I did as a test is to `ar x libname.a` into a subfolder `armembers` and then pass `armembers/*.o` on the command line instead of `libname.a`. – 0xC0000022L Sep 26 '12 at 12:26
  • possible duplicate: http://stackoverflow.com/questions/2193944/convert-a-static-library-to-a-shared-library-create-libsome-so-from-libsome-a – just somebody Aug 19 '13 at 16:56

1 Answers1

1

You could use the -u SYMBOL option to force objects to be read in from an archive.

% cc -c -fPIC a.c
% nm a.o
00000000 T a
% ar rv liba.a a.o
ar: creating liba.a
a - a.o
% gcc -o liba.so -shared -u a liba.a
% nm liba.so | awk '$3 == "a" { print }'
0000042c T a

One thing to check would be the spellings of the symbols being specified with --retain-symbols-file. For example, symbol names in objects compiled from C++ code are likely to be mangled:

% g++ -c -fPIC a.c
% nm a.o | awk '$2 == "T" { print }'
00000000 T _Z1av
jkoshy
  • 1,793
  • 15
  • 23
  • thanks. It's C-files and I'm aware of the mangling. Let me see whether `-u` will do the job. Because for all I know, I want to pull in some API functions (named in said file) and could simply use the file to create a command line. I checked the spelling of the symbols, btw. Unfortunately it's not the problem. – 0xC0000022L Sep 27 '12 at 16:31