构建多个平台的Linux二进制文件

帮助我解决分数问题。构建多个平台的Linux二进制文件

我有一个用C++编写的软件，它可以在尽可能多的Linux发行版上运行，我需要找出一个有效的策略。我试图在这种情况下运行二进制文件而不是源代码（可能很好知道）。 它已经是一个商业产品，我有知识产权问题，阻止我开源产品，但也意味着我必须处理无数的GPL问题。

推理的当前路线是选择一个最不常见的分母，并且建立一切。这有两个主要的含义，我觉得反作用。

旧版GCC中的C++支持缺少一些更新的C++特性。
最小公分母需要红帽企业Linux 4（RHEL4）

我绝对不需要整个C++ 11的功能设置，但我想带来的C++支持到那个Visual C++ 2010.我正在细读使用Clang/libC++而不是GCC/libstdC++的想法。我对RHEL4不同版本的Linux的ABI的稳定性没有多少见解，但是我担心RHEL4比值得的麻烦更麻烦。试图为所有基于少数几个发行版构建并不是一个可行的策略。

我假设编译用于不同发行版的Linux软件最好是通过目标平台上的工具编译目标平台的软件来完成。如果您不接受这一点，我目前也在假设您将跨Linux平台运行大量可移植性问题。不要谈论因为跨平台/发行版的C++ ABI不稳定而可以或不能链接的许多库。

但是我可能是错的，我想听取定期处理这个问题的人的意见。什么会起作用，为什么？或者更重要的是，哪些不起作用？

来源

2013-04-27 John Leidegren

如果我正在为软件付费如果我在Linux上报告一个很大的问题会发生什么情况 - 您肯定会支持一个产品，您必须在支持的Linux版本上测试产品 - 因此您必须拥有一个虚拟机为每一个和建立那里 – Mark 2013-04-27 11:27:21

@马克我的想法精确地说，它的工作正在进行中。 – 2013-04-27 11:34:22

http://stackoverflow.com/questions/2157636 | http://stackoverflow.com/questions/16250831 | http://stackoverflow.com/questions/15386027 – 2015-06-04 16:00:07

您可以尝试把重点放在几个主要的平台而不是个人分布。我的意思是建立在我称之为“基础发行版”（Debian和RedHat）的基础之上，并希望在其他方面取得最佳效果。

很可能，Debian二进制文件（静态链接的）在Ubuntu和Mint以及其他Debian派生的发行版上运行得很好。 RedHat二进制文件可能运行在Centos，Scientific Linux和SuSE Linux上。如果你关心的是不太受欢迎的发行版（假设你有很多客户运行一些不常见的Linux），并且你的Debian或RedHat可执行文件无法在其上运行，或者可以以某种方式工作，然后设置该发行版的虚拟机并构建一个可执行文件专门为那种味道。

我在过去采取了这种方法，它运行良好。

来源

2013-04-27 12:23:12

但是您推荐为Debian和RHEL分别使用二进制文件？ – 2013-04-27 13:27:20

最好的办法是让你的软件开放源码free software（例如GPLv3 +许可证），那么如果你的软件足够有趣，它将被分发（由分发维护者）打包。

你总是想提供分发包（例如Ubuntu或Debian的.deb文件），因为这些文件最容易安装。

如果你仍然想使专有软件（但问自己，如果你将能够出售，甚至分发免费，成功软件），你可以采取以下步骤：

通过启用一个静态stdC++ &静态libgcc（大多数发行版提供的GCC不这样做）来编译最近的GCC编译器（例如4.8）。
可能静态链接您的程序（但您可能无法执行此操作，例如相关功能，包括getaddrinfo和相关DNS服务）。

即使通过链接所有的C++相关的东西静态您还取决于libc.so.6，然后你可能有一些GNU库的版本问题（因此编译为一个libc的版本2.17的二进制不会总是与libc的运行2.16或反之亦然）。另外请注意，GNU libc通常与某些内核版本绑定（不能在某个相当老的内核上使用最近的libc）。你可以考虑像MUSL libc

一些替代的libc顺便说一句，你通常可以使用一些chroot -ed目标环境（其中可能会安装一些其他的分布，例如，与debootstrap）

来源

2013-04-27 10:51:39

我应该补充说它已经是一个商业上可行的软件包，但目前没有计划开放它的源代码。这是一个重大的知识产权问题，目前它必须保持封闭的来源。但是，感谢您的洞察力，其中一些将有助于挑选未来战略。 – 2013-04-27 11:33:02

如果有人很好奇，我们通过在RHEL 4.8 dist之上构建GCC 4.8工具链解决了这个问题，该工具链仍然是我们的构建代理。

它的症结在于here。由于我们不需要功能齐全的交叉编译器，问题稍微简单一些。只需在目标主机上安装GCC 4.8工具链即可。

互操作性仍然很痛苦，因为这个旧版本的Linux几乎不支持SMB和/或其他技术。我们结束了一个Bash脚本，它将构建输出放在一个FTP服务器中，这个工作非常合理。它解决了主要的难题。

来源

2017-02-06 10:40:19

构建多个平台的Linux二进制文件

回答

相关问题