Linking dependencies into static library / Partial linking

[Philip K.F. Hölzenspies]

On Wednesday 09 January 2008 16:58:41 Nick Clifton wrote:
> Hi Philip,
>
> > In the end, I would really like to have a libhebe.a file that only
> > exports the symbols of the wrapper AND does not contain unresolved /
> > undefined symbols that impose linker dependencies. Is this at all
> > possible?
>
> What you want is partial linking.  See the description of the --relocatable
> linker command line switch in the linker manual.  Couple that with whole
> archive linking and you should get the result you want.  ie something like
> this will probably work:
>
>    % gcc *.cc wrapper.o -Wl,--whole-archive -lglpk -Wl,--no-whole-archive
>      -Wl,--relocatable -o hebe.o
>
> Cheers
>    Nick


Dear Nick, All,

Thanks for the advice. However, I had already come across this option and not 
understood it earlier. I thought the --whole-archive would maybe prove to 
help me out, but it didn't. Because I want to avoid being sketchy, I took the 
liberty of creating a minimal example of where I don't understand ld's 
behaviour (on two counts).

Please see the files attached. To avoid stripped attachments, I figured I 
would also make this example available on my web-space. If you don't receive 
this e-mail with attachments, please see

www.cs.utwente.nl/~holzensp/ldtest.tgz

When running "make allcpp" you'll notice that the functions in cwrapper.cc and 
foo.h aren't found by the linker:

g++ -L. bar.c -lfoo -o bar
/tmp/cc6lYrCK.o: In function `main':
bar.c:(.text+0x12): undefined reference to `newFoo()'
bar.c:(.text+0x1a): undefined reference to `newFoo()'
bar.c:(.text+0x28): undefined reference to `doFoo(CFoo*)'
bar.c:(.text+0x33): undefined reference to `doFoo(CFoo*)'
bar.c:(.text+0x3e): undefined reference to `freeFoo(CFoo*)'
bar.c:(.text+0x49): undefined reference to `doFoo(CFoo*)'
bar.c:(.text+0x54): undefined reference to `freeFoo(CFoo*)'

However, "nm libfoo.a" disagrees:

holzensp@ewi1043:~/tmp/ldtest> nm libfoo.a

foo.o:
00000180 t _GLOBAL__I__ZN4CFooC2Ev
         U _Unwind_Resume
00000140 t _Z41__static_initialization_and_destruction_0ii
0000001c T _ZN4CFoo5doFooEv
0000000e T _ZN4CFooC1Ev
00000000 T _ZN4CFooC2Ev
000001b0 T _ZN4CFooD1Ev
000001f2 T _ZN4CFooD2Ev
         U _ZNKSs4sizeEv
         U _ZNKSsixEj
         U _ZNSolsEi
         U _ZNSt8ios_base4InitC1Ev
         U _ZNSt8ios_base4InitD1Ev
00000034 t _ZSt17__verify_groupingPKcjRKSs
00000000 W _ZSt3minIjERKT_S2_S2_
         U _ZSt4cout
00000000 b _ZSt8__ioinit
         U _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
         U _ZdlPv
         U _Znwj
         U __cxa_atexit
         U __dso_handle
         U __gxx_personality_v0
0000019c t __tcf_0
0000025e T doFoo
00000234 T freeFoo
00000272 T newFoo


Notice that the names are, indeed, unmangled, so the difference between the C 
and C++ interpretations of the CFoo type should not be an issue.

When running "make all" (using gcc instead of g++ for the compilation and 
linking of the C source to the library), the linker also wants to resolve 
stuff from the stdc++ library. I had hoped to have linked those in already.

Does this make any sense? Am I doing something wrong?

Regards,
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldtest.tgz
Type: application/x-tgz
Size: 1908 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20080112/c85019e1/attachment.bin>