静态链接GLIBC和专有软件许可 [英] Linking GLIBC statically and proprietary software licensing

问题描述

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

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




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

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

p>



 目标：x86_64-some-linux-gnu 
配置：/ 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 -w ith-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 
线程模型：posix 
 gcc version 4.4.7（crosstool-NG 1.15.3）
  




解决方案

使 libc.so 动态链接的原因有很多，包括法律和技术。





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





在技术方面，间接利用 libdl.so 或<$ c的所有特性几乎要求动态链接 libc.so $ c> ld.so -ie使用动态链接 - 特别是与NSS相关的函数（比如 getpwent 和 getaddrinfo 等等，参见 nsswitch.conf（5）& nss（5））。另外，动态链接libc效率更高（RAM几乎被所有使用 libc.so 的进程共享，并且可执行文件的大小更小;最重要的是，升级<$ c



顺便说一下，贵公司是否考虑过让你的Linux软件免费（如在演讲中）？它具有很多优点，许多公司都选择开源路线。




I have basic understanding problem with open source and licenses. Could someone please clarify some questions for the below scenario. Excuse me if it is very basic

1. I'm writing a proprietary software in which i plan to use some open source libraries. I will also need glibc and a C compiler, but did not want to use the default gcc toolchain from my OS, so built my own using crosstools-ng

2. Now in ct-ng, i guess the libstdc++ library gets linked statically(which is for c++ and i won't be using that in most case i guess) but from my toolchain configuration is my libc statically or dynamically linked? If that is the case, given that glibc is LGPL, and that i can link it to my proprietary software, will this static linking cause any issues to me wrt licensing? Can my software still be close sourced? or do i have to release the compiled objects.

My toolchain configuration is below, from this could someone point to me if glibc is statically or dynamically linked?

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) 

解决方案

There are many reasons, both legal and technical, to make libc.so dynamically linked.

On the legal side, the LGPL license of GNU libc requires you to permit your users to enhance their libc; so if you sell a proprietary software which is statically linked (a technically bad idea), you need to give the means to your user to relink it to a better version of libc; concretely you'll probably need to also give the *.o object of your software.

On the technical side, dynamically linking libc.so is nearly required by all features taking indirectly advantage of libdl.so or of ld.so -i.e. using dynamic linking-, in particular the NSS related functions (like getpwent and getaddrinfo and many others, see nsswitch.conf(5) & nss(5)). Also, dynamically linking libc is much more efficient (the RAM is nearly shared by all processes using libc.so and the executable size is smaller; and most importantly, upgrading libc.so is easier).

BTW, did your company considered making your Linux software free (as in speech)? It does have many advantages, and many companies are choosing the open source route.

这篇关于静态链接GLIBC和专有软件许可的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！