最小化Linux共享库的依赖关系

我正在编写一个共享库，我正在Windows，Linux和Mac下部署。在Linux方面，我试图确保我的库具有尽可能少的依赖关系。我不希望最终开发者不得不担心我的库在内部使用什么，特别是我不想强迫他们安装任何东西。最小化Linux共享库的依赖关系

当我在此刻运行在我的图书馆LDD，我看到：

linux-gate.so.1 => (0xf57fe000)           
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb773d000)  
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7654000) 
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74a1000)     
    /lib/ld-linux.so.2 (0xb7782000)           
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb745d000)     
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7440000)

这看起来相当合理的，我的，但一些图书馆的我真的不知道它们是什么。任何人都可以告诉我，这个依赖关系列表是否合理，还是我可以摆脱其中的一些？有了这个依赖列表，我的库可以运行在各种Linux配置和发行版上吗？这是我的目标，最大的便携性。

编译时，我指定了标志-static-libgcc。例如，是否还有更多的标志可以指定在C++标准库中链接？在内部，我的库在C++ 11中使用std :: thread，但我不想强制应用程序编写者必须具有可用的（如果他们使用的是较旧版本的GCC）。

更新：

我现在指定-static-的libstdC++，除了-static-libgcc中。我的依赖列表现在看起来如下：

linux-gate.so.1 => (0xf57fe000)           
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7737000)  
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7584000)     
    /lib/ld-linux.so.2 (0xb77a2000)

的，仅仅是引起了我的关注是libc.so.6的，和linux-gate.so.1。我不知道这些是什么。他们是否老了，如果有的话，他们已经长期向后兼容？如果是这样，我会保持它们动态链接，否则我必须继续调查。任何提示将不胜感激。

来源

2013-08-29 Philip Bennefall

你想要定位哪个linux发行版？我认为这是一个难以解决的问题。 – trojanfoe

尽可能多。我没有特别的喜好。我的生成机器是Ubuntu 13,32位。 –

这是非常复杂的。一种选择是为您的开发者客户提供一个静态库，但仍然有一些运行时间解决方案可以解决这个问题。 – trojanfoe

linux-gate.so.1是一个虚拟的DSO，这意味着它并不存在。解释它的最好方法就是阅读这个链接Here。

要回答你的问题，我认为你的最佳选择是继续动态链接到他们两个，并做一些不同的构建目标不同的发行版。我发现通常在为Ubuntu构建时，它可以在几个Debian Linux系统上运行。

来源

2013-08-29 14:28:01

谢谢。你能否推荐一些我可以为其构建的其他发行版，这会间接地对其他发行版起作用？我在这里有Ubuntu，但有能力虚拟安装其他人。你能推荐任何能给我带来最佳覆盖率的主要产品吗？ –

Fedora（又名红帽），Ubuntu和Suse的构建会给你很好的覆盖。许多发行版都基于Debian或红帽，因此这两者将会走很长的路。 –

谢谢！非常感激。 –

最小化Linux共享库的依赖关系

回答

相关问题