Question

关于lib文件以及linux下软件生成方式的疑问

就像dx 基础库中的那些东西，如果要使用的话，为什么要自己编译生成lib文件了，直接微软提供现成的lib文件不就行了吗？
同样对于linux下软件生成的方式也不理解。不少都是提供的源码，需要自己用提供的make编译，其实直接提供一个供用户使用的程序不就行了吗？linux下好像也是有一些是这样做的啊？
想到一个可能，是不是生成的lib可能要调用操作系统的一些库，所以要编译一下，确定那些库在哪里?这样的话，是不是不少时候就不可以直接用其他电脑上编译得到的lib文件。

Answer 1

lib 库随时可以用，但有一个问题就是函数入口的问题。这也是为什么就算你机器里面有 DX ，你写 DX 程序时依然需要 DX 的 SDK （虽然现在 VS 都自带，但以前可不自带）。
所以编译程序需要的其实不是 lib ，而是 C header 一类的东西。以及函数入口信息的文件（现在不知道还需要不需要了）
其次还有就是函数库编译时的参数，Linux 很灵活，所以有的时候，某个函数库可以提供多种不同的功能配置。这也需要你考虑。

至于现成的程序，确实可以直接提供一个能用的程序就行，但这里还有一个问题就是，你能否确定系统里面真的完全都有你使用了的函数库？函数库的入口是不是完全和你的程序入口一样（以前这个问题很严重，现在好了很多，而且还有 LSB 规范）。
现在 oracle 和 SAP 这种企业级的程序，都是二进制程序商业软件发布，没有源代码。人家的程序不也很正常的使用么。不过人家都是有认证的，他们会告诉用户，他们的程序在那些 Linux 发行版上进行了测试，没有问题，而且他们的程序也都遵循 LSB 的规范保证兼容）。

Linux 的一个“大”问题就是整个系统不是一个单位、组织或者个人开发的，他是上百上千的软件组成的，每个软件都有独立的开发组进行独立的开发进度，这很难保证每个软件的兼容性和可移植性。所以很多软件的编译过程最开始的 ./configure 都有很多的环境监测步骤。而且这成百上千的程序集中到一起还不能出现互相不兼容而导致整个系统挂掉，从源代码编译可以很好的解决函数入口版本等等问题的出现。

至于函数库在什么地方，这也是一个坑人的问题，尤其是很多新手无脑看教程安装，把 lib 安装到非系统特定目录里面，程序也一样会找不到 lib 文件而不能运行。不过相对来说 Linux 的文件存储规范还是比较靠谱的。Windows 的 dll 地狱问题其实现在依然无解，不过微软的整个系统的掌控能力还是可以把函数库版本导致的兼容问题降低到最小。不过这也是为什么 Windows 越来越大的一个原因，整个系统里面的函数库从 Windows 3.1 开始就要提供兼容。现在放弃旧版 Windows 支持后，马上就有人过来喷 Windows Vista/7 的兼容烂。

所以目前来说，根本没有必要去想为什么 Linux 的软件要源代码发布。这个问题最根本的原因就是人家要的就是直接发布源代码，想用软件你们自己编译去。

如果你还是不能理解这个问题，一个很简单的办法：
装套 RH9 。之后更新 glibc 到 Fedora 16 的版本，你看看系统还能不能启动就知道了。
以前我经常看到的问题就是某些人没事升级 glibc ，导致连 bash 命令行都不能使用的情况。直到 glibc 好像是 2.7 开始 ，gcc 3.3 开始吧，函数库的入口和版本兼容问题才有所缓解。