在Linux上创建一个静态的C库,可以在不同版本的GCC之间进行移植

4
我想分发一个静态C库(.a)作为二进制文件。
给定特定的CPU架构和平台(例如armv6 / Raspi):
- 是否可以创建单个二进制文件,适用于所有不同的GCC版本,即是否有跨不同GCC版本的ABI?
- 是否可能还可以从Clang使用相同的二进制文件?
如果不能,我需要为哪些GCC版本创建不同的二进制文件?是否可以使用非常旧的GCC来构建二进制文件,并期望新的GCC版本正确链接它?
如果需要多个二进制文件:有没有流行的软件被分发为静态库(.a文件),可以作为参考,了解如何做到最佳实践?
共享对象(.so)是否比静态库(.a)更好?是否有Linux定义的ABI允许使用不同GCC版本编译的程序导入.so或.a库?
此问题与C ++无关。所讨论的库仅使用C99并且完全可移植,即甚至不依赖于标准库。
1个回答

3

对于成熟的目标,GCC版本不会影响ABI。 您可以升级并继续使用旧的二进制文件。 这也适用于切换到Clang。

但是,如果您的库依赖于其他部分(即使只是glibc),则在构建库时,您会冻结头文件中的声明和定义,这些依赖关系的未来演变可能会导致今天的内容与用户在将来几个月或几年内安装的内容不兼容。

GNU工具链对于动态链接共享对象的ABI管理有更好的支持:正确连接到glibc或libgcc的内容将继续长时间工作。 对于静态库,这个关键的链接步骤没有发生,因此ABI依赖关系没有被正确编码到生成的静态库中。


在我的情况下,没有依赖标准库。这是纯可移植的代码。另外:您介意链接一些官方文档来支持GCC .o / .a文件的ABI稳定性吗?此外,Clang二进制文件也能被GCC使用,还是只有反过来?如何找出什么是“成熟的目标”? - Etan
另外,像short-enums这样的标志又怎么办?即使使用共享对象,如果一个库不要求所有客户端使用完全相同的标志,它怎么能够具有可移植性呢? - Etan
@Etan: 短枚举(short-enums)是一项破坏ABI的选项,你根本不应该使用它。如果有人使用了它,那就是他们自己造成了问题。 - R.. GitHub STOP HELPING ICE

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接