背景
我正在制作一个应该在 Centos 7 上运行的 C++ 应用程序。构建是在 Centos 7.9 上完成的，我使用的是 C++11 和 C++17 功能，这限制了与旧版本 Centos 7 的向后兼容性。有一个安装程序可以在用户运行应用程序之前执行一些检查。
问题
如何自动确定我正在开发的应用程序支持的最低 Centos 7 版本？
我目前拥有什么
ldd现在，在构建之后，我正在使用and检索所需库的列表readelf（请参阅：https://stackoverflow.com/questions/6242761/define-direct-shared-object-dependency-of-a-linux-binary）。通过该列表，我可以将用户拥有的内容与我的应用程序需要的内容进行比较，如果用户的版本低于要求，安装程序会告诉他升级。然而，通过这种方法，我的列表告诉我构建机器上的库的版本是什么，而不是它们的最旧的兼容版本。
我认为我会做的是将我的构建机器降级到 Centos 7 的某个版本，并且 - 如果应用程序编译 - 说这是支持的最低版本。然后安装程序会将用户的库版本与生成的列表进行比较。话虽这么说，我希望得到某种承诺，即新版本与我将使用的版本向后兼容，但我在 Centos 或 Red Hat 的网页上找不到类似的内容。使用较旧的、不受支持的操作系统版本还存在安全问题。
第二个选择是只支持我的构建机器上的任何内容，但这可能需要一些用户升级，他们可能不喜欢它。
第三种选择是构建应用程序并尝试在旧版本的 Centos 上运行它。
我的最大问题是缺乏如何在数据包管理器之外分发 Linux 应用程序的知识。在 Windows 上，您只需将所有 DLL 与 EXE 打包在一起就可以了（大多数时候）。然而在 Linux 上你不能这样做（我的意思是，你可以搞乱 RPATH...）。
答案1
这仅有的任何 RHEL 的受支持版本$release都是该$latest版本，例如，对于 7，它将是 7.9。针对旧版本是浪费时间和资源。如果您的潜在客户正在运行与 7.9 不同的版本，他们就会欢迎严重的安全漏洞。
我的最大问题是缺乏如何在数据包管理器之外分发 Linux 应用程序的知识。
- 作为 flatpak/snap/appimage 发布（我通常不喜欢这种方法，但 Linux 发行版早已埋没最低有效位）
- 如果您的应用程序是开源的，您可能会将其与所有内容静态链接（这是一个非常糟糕的主意）
- 以源代码形式分发，让需要的人自行编译