如何符号在Linux
结合工作共享库编译时使用g ++一段cpp的程序-O0我发现我的二进制文件不包含空字符串符号（basic_string的）： _S_empty_rep_storage 当我做编译相同的程序与-O2我注意到，上述符号二进制内确实包含如下（在仓使用纳米）：如何符号在Linux
00000000006029a0 V _ZNSs4_Rep20_S_empty_rep_storageE @@ GLIBCXX_3.4
我的应用程序使用几个。所以（动态库），当我的应用程序加载时，我注意到几个这些.so文件绑定如下（我设置LD_DEBUG =所有跑我的程序）：
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]**
但我也注意到我的。所以一个唯一的结合如下：
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]
，但从来没有如上所示为mydynamiclib.so绑定二进制文件（mytestapplication）。
所以我想知道这实际上是什么意思？这是否意味着anotherdynamiclib.so将对应用程序的其余部分使用不同的符号作为空字符串？我想我真正要问的是在上面的例子中，符号绑定是如何工作的？
谢谢！
恐怕我不完全理解你的问题，但你可能会在Ulrich Drepper的论文How to write shared libraries中找到答案。这是我知道的关于在Linux中如何使用elf可执行文件的最好方法。
我很难解析你的问题。如果您包含一小段代码，那么您正在编译它可能会有所帮助。
我注意到，上述符号二进制中确实包含如下 这取决于你的意思“载”。符号表中有该符号的条目，但是它是外部符号，而不是应用程序“导出”的符号。请注意名称中的@@ GLIBCXX_3.4。符号的实际位置在GLIBCXX中（看起来它实际上解析为libstdC++）。
从你的输出，纳米不会出现实际显示ST_BIND信息（在El32_Sym/Elf64_Sym结构st_info字段的一部分）。这是确定链接器如何处理符号绑定的信息。你可以运行 readelf -s YOURBINNAME 它会显示绑定。