How does symbol binding work for shared libraries in linux

When compiling a cpp program with g++ -O0 I noticed that my binary does not contain the symbol for the empty string (basic_string): _S_empty_rep_storage When I do compile this same program with -O2 I notice that the aforementioned symbol is indeed contained within the binary as follows (using nm on the bin):

00000000006029a0 V _ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4

My application uses several .so (dynamic libraries) and when my aplication loads I notice that several of these .so files bind as follows (I set LD_DEBUG=all and ran my program):

 28596: binding file /home/bbazso/usr/local/lib/mydynamiclib.so [0] to /usr/lib64/libstdc++.so.6 [0]: normal symbol `_ZNSs4_Rep20_S_empty_rep_storageE' [GLIBCXX_3.4]
 28596: binding file /home/bbazso/usr/local/lib/mydynamiclib.so [0] to /home/bbazso/workspace/mytestapplication [0]: normal symbol `_ZNSs4_Rep20_S_empty_rep_storageE' [GLIBCXX_3.4]
 28596: binding file /home/bbazso/workspace/mytestapplication [0] to /usr/lib64/libstdc++.so.6 [0]: normal symbol `_ZNSs4_Rep20_S_empty_rep_storageE' [GLIBCXX_3.4]**

But I also noticed that one of my .so only binds as follows:

  28087:    binding file /home/bbazso/usr/local/lib/anotherdynamiclib.so [0] to /usr/lib64/libstdc++.so.6 [0]: normal symbol `_ZNSs4_Rep20_S_empty_rep_storageE' [GLIBCXX_3.4]

but never binds to the binary (mytestapplication) as shown above for the mydynamiclib.so.

So I was开发者_如何学Python wondering what this actually means? Does this mean that anotherdynamiclib.so will use a different symbol for the empty string above than the rest of the application? I guess what I'm really asking is how does symbol binding work in the context of the example above?

Thanks!

---

I am afraid I don't fully understand your question but you might find an answer in a Ulrich Drepper paper called How to write shared libraries. It is the best I know regarding how symbols with elf executables in Linux.

---

I have difficulty parsing your question. If you included a small snippet of example code that you are compiling it might help.

I notice that the aforementioned symbol is indeed contained within the binary as follows It depends what you mean by "contained in". There is an entry for that symbol in the symbol table, but it is an external symbol, not a symbol that your application is "exporting". Note the @@GLIBCXX_3.4 in the name. The actual location of the symbol is in GLIBCXX (which looks like it actually resolves to libstdc++).

From your output, nm does not appear to actually show the ST_BIND information (part of the st_info field in the El32_Sym/Elf64_Sym structures). This is the information that determines how the linker treats the binding of the symbol. Can you run readelf -s YOURBINNAME It will show the bindings.