views:

213

answers:

1

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 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!

A: 

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.

fco.javier.sanz