静态链接glibc和libstdc ++

Question

我正在编写一个不兼容GNU GPL的跨平台应用程序。我目前面临的主要问题是应用程序与glibc和libstdc ++动态链接，几乎每个库的新主要更新都不向后兼容。因此，在我的应用程序中可以看到随机崩溃。

作为一种解决方法，我分发在几个不同系统（具有不同C / C ++运行时版本）上编译的应用程序的二进制文件。但我想没有这个。所以我的问题是，保持许可和一切，我可以静态链接glibc和libstdc ++吗？此外，这是否会导致rtld？

出现问题

Answer 1

你不需要。

将您链接的原始库复制到应用程序文件夹中的目录（本例中为../lib）。

像：

my_app_install_path

1. 的.bin
2. LIB
3. 文档

将应用重命名为app.bin之类的应用。将您的应用替换为一个小的shell脚本，将环境变量LD_LIBRARY_PATH设置为库路径（并连接以前的LD_LIBRARY_PATH内容，如果有的话）。现在ld应该能够找到你链接的动态库，而不需要将它们静态编译到你的可执行文件中。

请记住遵守LGPL，将给定的归属添加到库中，并指向可以下载源代码的文档。

Answer 2

为链接器指定选项-static-libgcc会导致它链接到C库的静态版本（如果在系统上可用）。否则会被忽略。

Answer 3

glibc属于LGPL。在LGPL 2.1的第6部分下，如果您符合五个选项之一，则可以分发链接到库的程序。第一个是提供库的源代码，以及您自己的程序的目标代码（源是可选的，不是必需的），因此可以与库重新链接。您也可以提供相同的书面报价。您自己的代码不必属于LGPL，您也不必释放源代码。

libstdc ++属于GPL，但有major exception。您基本上可以根据您选择的许可进行分发，而无需为您自己的代码或libstdc ++提供源代码。唯一的条件是你正常编译，没有例如GCC的专有修改或插件。

IANAL，如果您需要真正的法律建议，您应该考虑咨询。

Answer 4

我必须质疑你在糟糕的图书馆功能方面做了什么？

我也有一些跨平台软件。它在各种Linux系统上运行良好。使用您想要支持的最旧版本的软件构建。 glibc和libstdc ++库实际上非常向后兼容。

我已经在CentOS 4上构建并在RHEL 6 beta上运行它。没问题。 我可以在稳定的Debian上构建并在测试时运行它。

现在，我有时会遇到一些库，如果我尝试构建，比如老Debian并尝试在CentOS 5.4上运行它。这通常是由于分布配置选择不同，例如选择线程或非线程。