我的问题是,许多图书馆不能很好地处理,他们忘记明确地导出符号,这是一个严重的问题.经过几个固定的bug甚至一些部分的提升可能还会受到影响.当然这些bug应该是固定的,但直到那时我想用一种“安全”的方式尽可能地隐藏符号.
我想出了一个解决方案：我把所有的符号放在一个命名空间,我使用符号隐藏属性,并导出公共接口,这样只有我的符号可以受到影响.
问题是,当我为我没有导出的每个类编译某些对象时,我收到一条警告消息,我在应用程序中用作类字段.
namespace MyDSO __attribute__ ((visibility ("hidden"))) {
struct Foo {
void bar() __attribute__ ((visibility ("default"))) {}
};
}
struct Bar {
MyDSO::Foo foo;
};
int main() {}
可以在这个小例子中再现警告消息,但是当然这个命名空间应该在应用程序中的另一个类库中.
$gcc-4.7.1 namespace.cpp -o namespace namespace.cpp:7:8: warning: ‘Bar’ declared with greater visibility than the type of its field ‘Bar::foo’ [-Wattributes]
当我理解符号可见性时,隐藏命名空间应该与使用-fvisibility = hidden有相似的效果,但是我从来没有使用后者来得到类似的警告.我看到当我通过-fvisibility =隐藏应用程序时,应用程序中的类也将被隐藏,所以我不会收到警告.但是当我没有传递选项时,标头中的符号似乎不会隐藏到编译器中,所以我不会再发出警告.
这个警告信息的建议是什么？这是一个严重的问题吗？在哪种情况下可能会导致任何问题？隐藏命名空间与隐藏=隐藏有什么不同？
解决方法
关于你的具体问题,GCC是正确的警告你.如果外部用户试图使用公共类型的Bar,他们几乎肯定需要使用Bar中的所有内容,包括Bar :: foo.由于完全相同的原因,所有私人会员功能,尽管是私人的,需要是可见的.很多人都对此感到惊讶,推测私人成员函数符号根据定义无法访问,但他们忘记只是因为程序员无法访问并不意味着编译器不需要访问.换句话说,私有成员函数对您是私有的,而不是编译器.如果它们出现在头文件中,那通常意味着编译器需要访问,即使在匿名命名空间中(这对于程序员来说只是匿名的,而不是使用倾向于将内容的哈希值作为“真实”命名空间名称)的编译器).
隐藏命名空间对-fvisibility = hidden有非常不同的影响.这是因为GCC排除了特定类型以外的许多符号,例如对于vtables,对于type_info等.-fvisibility =隐藏的隐藏的东西,你不能隐藏任何编译器指示的方式,这是绝对必要的加载两个二进制文件到相同的进程与冲突的符号,例如使用不同版本的Boost构建的两个共享对象.
感谢您尝试解决由ELF中的符号可见性损坏引起的问题,以及对破坏的C二进制文件的后果以及程序员生产力的损失.但是你无法修复它们 – 它们是ELF本身的错误,它是为C而不是C设计的.如果有任何的安慰,我在几个月前就写了一篇关于这个话题的内部黑莓白皮书,因为ELF符号可视性问题对于我们在BB10而言是一个很大的问题,因为它们对于具有重要C代码库的任何大公司来说都是一个问题.所以,也许你可能会看到为C 17提出的一些解决方案,特别是如果Doug Gregor的C模块实现取得了很好的进展.
