我正在编写一个脚本，使uClibc可用于现有的glibc目标gcc / binutils工具链，而我留下的一个问题是pthread_cancel需要dlopen {{ 1}}。随主机gcc提供的版本链接到依赖于glibc，因此我使用libgcc_s.so.1的{{1}}选项从ld中提取所需的符号（及其依赖项）替换-u：
libgcc_eh.a原则上我会完成，但libgcc_s.so.1中的所有符号都将其可见性设置为隐藏，因此在输出gcc -specs uclibc.specs -Wl,-u,_Unwind_Resume -Wl,-u,__gcc_personality_v0 \
-Wl,-u,_Unwind_ForcedUnwind -Wl,-u,_Unwind_GetCFA -shared -o libgcc_s.so.1
文件中，它们都变为本地，并且不会添加到libgcc_eh.a符号表。
我正在寻找一种在.so文件或.dynsym文件中使用binutils（可能是objcopy？或链接描述文件？）的方法隐藏这些符号。这可能吗？
答案 0 :(得分：1)
我认为你应该能够在objcopy中使用--globalize-symbol。
e.g。
$ nm /usr/lib/gcc/i686-redhat-linux/4.6.3/libgcc_eh.a | grep emutls_alloc 00000000 t emutls_alloc $ objcopy --globalize-symbol=emutls_alloc /usr/lib/gcc/i686-redhat-linux/4.6.3/libgcc_eh.a /tmp/libgcc_eh.a $ nm /tmp/libgcc_eh.a |grep emutls_alloc 00000000 T emutls_alloc
您可以多次向objcopy提供--globalize-symbol，但是您需要明确提及要全局化的所有符号的完整符号名称。
虽然我不确定将libgcc_eh.a变成共享对象会发生什么样的破坏，因为libgcc_eh.a可能是在没有-fpic / -fPIC的情况下编译的。 结果证明libgcc_eh.a被编译为与位置无关的代码。
答案 1 :(得分：1)
objcopy似乎没有此功能，但是您可以使用ELFkickers rebind tool来做到这一点：
rebind --visibility default file.o SYMBOLS...
这必须在原始.o文件上完成。如果您尝试在.so上执行此操作，那将为时已晚，因为在.dynsym部分中将省略隐藏的符号。