请问发布 C++的 SDK 需要在不同的 Linux 发行版本上编译再发布吗？兼容不同的 Linux 发行版本
vinckdu997 · 2022-12-11 09:51:04 +08:00 · 3384 次点击这是一个创建于 697 天前的主题，其中的信息可能已经有所发展或是发生改变。
怎样保证这些库在不同的操作系统上能跑起来？
 |
1
msg7086 2022-12-11 10:07:25 +08:00
C++ SDK 不是源码么。
库的话一般都会针对每个发行版单独发一个版本。也可以挑最老的系统编译，给新系统用。 |
 |
2
yolee599 2022-12-11 10:31:07 +08:00 via Android
只是 Linux 系统的话，应该只需要区分 arch 就行了，比如 x86 ，arm 等，跟发行版本关系不大，arch 一致就能运行
|
 |
3
BrettD 2022-12-11 10:37:26 +08:00 via iPhone
需要考虑目标系统上 glibc 和 libstdc++版本的问题
|
 |
4
vinckdu997 OP @msg7086 #1 是库
|
 |
5
lifanxi 2022-12-11 11:32:47 +08:00
要么静态链接，但是后期各种基础库有安全漏洞之类的更新起来要会命。
要么按不同的发行版分别构建。 |
 |
6
nightwitch 2022-12-11 12:43:37 +08:00
可以源码发行的话，提供不同发行版的编译脚本就可以了。
成熟的 cpp 程序员会自己处理编译问题。 只能提供 lib 的话，在 https://github.com/pypa/manylinux 这个镜像下能编过的东西，在绝大多数 linux 上都能跑起来 |
 |
7
cnbatch 2022-12-11 16:21:56 +08:00
确实最好还是针对每个 arch 以及每个 libc / libstdc++ (libc++) 分别编译。
libc 不仅仅有 glibc ，还有 musl 这是大坑，尽管默认使用 musl 的发行版并不多 |
 |
8
mingl0280 2022-12-11 16:29:53 +08:00 via Android
更准确的说是，每个 arch 每个 libc/libstdc++版本均需要一次编译。
libc 每次更新都不一定会兼容之前版本的 ABI ，会出事。例如，libc 2.27 2.34 互不兼容，如果你的库编译面向了 2.34 ，那么 2.27 跑不了；编译了 2.27 的版本，2.34 跑不了。 |
|
9
BrettD 2022-12-11 16:41:05 +08:00 via iPhone
@mingl0280 glibc 不是向后兼容的吗，为什么会有编译 2.27 版本在 2.34 跑不了的情况
|
 |
10
Authorization 2022-12-11 17:34:03 +08:00  1
是的，如果您要发布一个 C++ 的 SDK ，那么您需要在不同的 Linux 发行版本上编译该 SDK ，然后再将编译后的版本发布出去。
这是因为 Linux 操作系统有许多不同的发行版本，每个发行版本都有自己的库文件和系统环境。如果您在一个特定的 Linux 发行版本上编译了您的 SDK ，那么您发布的版本可能只能在该发行版本上运行，而不能在其他发行版本上运行。 因此，为了让您的 SDK 能够在所有 Linux 发行版本上运行，您需要在所有常用的 Linux 发行版本上编译该 SDK ，然后将所有版本都发布出去。这样，您的用户就可以在自己的 Linux 环境中使用您的 SDK 了。 如果您不确定您的 SDK 能否在所有 Linux 发行版本上运行，您可以尝试在多个不同的 Linux 发行版本上编译和测试您的 SDK 。这样，您就可以确保您的 SDK 能够在所有常用的 Linux 发行版本上运行，从而为您的用户提供最佳的体验。 来自 chatgpt 的回答！！！ |
 |
11
jim9606 2022-12-11 18:01:31 +08:00
用你打算支持的最低版本的 glibc/libstdc++/libgcc_s/GCC 组合来编译，近 10 年这三个库是向后兼容的。
通常 glibc 比较难更换，所以通常是找打算支持的最旧发行版作为基础编译环境，后两者是跟 GCC 捆绑的。 另外你可以试下用 -shared -fPIC -static-libgcc -static-libstdc++ 选项组合编译动态库，但我不清楚一个进程可不可以混用这种方式链接的库。 全套换成 musl 也可以，但你的库的上下游也只能用 musl 了，musl 缺的一些特性可能会很麻烦。 |
 |
12
neoblackcap 2022-12-12 02:28:59 +08:00
我看 protobuf 之类的库，都会选择一个 glibc 版本来进行兼容处理。然后把你的 SDK 通过 C API 暴露。同时在头文件处进行再封装(C++)。
|
 |
13
noroot 2022-12-12 15:22:27 +08:00
保证系统调用的 ABI 兼容，然后静态编译。
|
 |
14
8675bc86 2022-12-12 21:29:11 +08:00
这个非常难做到。
只要你的 C++ 有动态链接库依赖，所有的动态库版本能保证一样吗？ linux 下的各个包的动态库名字 xxx.so.1/2/3/4 可是一直在增长的。 如果找不到，启动的时候直接报错。 还有 glibc 的 ABI 等等。仅仅兼容 CentOS 7 和 Fedora 36 这两个发行版都可以把人折磨的够呛。 |
 |
15
xiaoxuxu 2022-12-20 19:17:26 +08:00
如果是要发行动态库的话，用 CentOS 7 容器镜像，装 Devtoolset （最新应该有 gcc/g++-10 ），来编译。基本上近几年的发行版都能直接兼容。目前 python 的 numpy 这些库都是这么编的。
|
|
16
vinckdu997 OP 我是在 centos7 上编译的，能兼容大部分苦，但是 centos7 生命周期已经终结了， 我是不是要升级到新一点的版本上来编译？？？谢谢
|
Select Language