链接GLIBC静态和专有软件许可

Question

我对开源和许可证有基本的理解问题。有人可能请澄清以下情况的一些问题。对不起，如果它是非常基本的

1. 我正在写一个专有软件，我打算使用一些开源库。我也需要glibc和一个C编译器，但不想使用我的操作系统默认的gcc工具链，所以我自己使用crosstools-ng

2. 现在在ct-ng中，我猜libstdC++库被链接静态（这是C++和我不会用在大多数情况下，我猜），但从我的工具链配置是我的libc静态或动态链接？如果是这样的话，鉴于glibc是LGPL，并且我可以将它链接到我的专有软件，这种静态链接是否会导致我的许可问题？我的软件能否靠近来源？或者我必须释放编译的对象。

我的工具链配置如下，从这可能有人指向我，如果glibc是静态或动态链接？

Target: x86_64-some-linux-gnu 
Configured with: /home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/src/gcc-4.4.7/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=x86_64-some-linux-gnu --prefix=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu --with-sysroot=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu/x86_64-some-linux-gnu/sysroot --enable-languages=c,c++,fortran --with-pkgversion='crosstool-NG 1.15.3' --disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-mpfr=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-ppl=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-cloog=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-target-optspace --with-long-double-128 --disable-multilib --with-local-prefix=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu/x86_64-some-linux-gnu/sysroot --enable-c99 --enable-long-long 
Thread model: posix 
gcc version 4.4.7 (crosstool-NG 1.15.3) 

Answer 1

原因是多方面的，既有法律和技术，使libc.so动态链接。

在法律方面，GNU libc的LGPL许可证要求您允许用户增强其libc;所以如果你销售一个静态链接的专有软件（技术上不好的想法），你需要让用户把它重新链接到一个更好的libc版本;具体来说，您可能还需要提供软件的*.o对象。

在技术方面，动态链接libc.so几乎需要间接利用libdl.so或ld.so -i.e.的所有特征。使用动态链接 - 尤其是NSS相关功能（如getpwent和getaddrinfo等等，参见nsswitch.conf(5) & nss(5)）。此外，动态链接libc效率更高（RAM几乎与所有使用libc.so的进程共享，并且可执行文件的大小更小;最重要的是，升级libc.so更容易）。

顺便说一句，您的公司是否考虑让您的Linux软件免费（如在演讲中）？它确实有很多优点，许多公司正在选择开源路线。