我们即将发布一些支持Linux的软件。
对于Mac和Windows，支持的版本数量非常有限（xp，2000，vista，7为win，10.4-6为Mac）。但对于Linux来说，这是另一个故事。
我们希望尽可能多地支持Linux，但选择范围很广。
问题是：
我们的软件是用ANSI兼容的C编写的，带有一点BSD和POSIX（gettimeofday，pthreads）。
答案 0 :(得分：3)
所以你认为Mac和Windows各有三个版本是正常的，但是你回避Linux？嗯。
请确保使用传统的标准工具链configure，make和make install进行构建。其余的应该照顾好自己。
否则，选择你喜欢的东西。对我来说，这将是Debian / Ubuntu，其他人更喜欢Fedora。查看Linux标准库以及FreeDesktop.org等其他标准。除非你正在做一些非常硬件或特定于驱动程序的事情，否则内核和libc应该无关紧要。
答案 1 :(得分：0)
内核努力维护向后兼容的二进制API。针对1.0系列内核构建的静态链接二进制文件在最新的2.6系列内核上仍然可以运行到今天。
如果您静态链接所有内容（包括libc），那么您可能遇到的主要问题是不同的文件系统安排，这对您来说可能不是一个很大的问题。 （尽管如此，测试是唯一可以找到的方法。）
答案 2 :(得分：0)
一个想法是调查您建议的客户群，以便查看他们运行的Linux版本，并根据他们的反馈列出一个简短列表。但据我所知（这是主观的！）......
我建议运行两种不同的分发类型 - rpm和.tar.gz。使用rpm，您可以满足最新的Fedora / openSUSE / RHEL / SLES（以及派生的发行版，这是公司市场的一大块）。您已经通过静态链接处理了很多依赖性问题，因此内核版本应该足够了。
使用.tar.gz发行版，您可以满足“所有其他人”的需求，但会看到支持和配置问题，因为它们很快会成为时间的下降。
要进行测试，请选择要支持的每个版本的虚拟机。这些也可以用于产品支持（我假设您需要提供产品支持？）我不会尝试在Linux版本之间推断结果，因为有太多隐藏的'陷阱'。
答案 3 :(得分：0)
你可以针对内核发布静态编译的Linux二进制文件。 glibc的版本。您真的只需要担心兼容性破坏修订。如果您有时间，可以设置在同一主机上交叉编译的所有内容。内核向后兼容。 glibc更有气质。
如果要使用安装程序将文件路径打包，可以假定它们是Linux Standard Base。你在这里越灵活越好。我从来没有听到客户抱怨收到二进制文件的tarball，我建议提供。我让客户抱怨错误的假设。
正式包格式的最佳选择可能是DEB（Debian Linux和衍生产品，如Ubuntu）和RPM（Red-Hat＆amp;衍生产品，如Cent-OS）之间。软件包很不错，但如果您不打算使用本机更新管理器，那只会很头疼。
对于测试＆amp;构建，我个人推荐Gentoo。然而，它非常原始，所以你可能希望将Ubuntu视为遥远的第二选择。
答案 4 :(得分：0)
这是您的产品管理团队的问题。一旦他们确定生产Linux版本是一个理想的想法（即基于成本效益），那么您将需要找出客户使用或希望支持的发行版。
原则上你可以支持任何一个，但是你支持的越多，它就会越多，所以你想尽可能少。
支持它们的难度在很大程度上取决于您的产品的复杂程度（尤其是依赖关系）以及其自动测试套件的完整程度。添加更多支持的操作系统会使您的手与库使用，内核功能使用等以及测试相关联，因此您不希望长期使用它。
简而言之，它不是软件工程问题，而是产品管理问题。