This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
ldtest.tgz
Description: application/tgz
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |