这常被称为二进制文件的去皮或去壳
这也可以在编译的过程就来完成，就是编译的时候使用特定的参数来要求编译器进行特定的操作。

编译原理:
http://book.hitce.net/view.asp?id=213
另外更好的有:
http://book.chinaunix.net/showbook.php?id=16341
但找不到电子版

原代码在可移植性上的问题
http://www.linuxfans.org/nuke/modules.php?name=Site_Downloads&op=geninfo&did=4532

希望有人提供二进制代码的可移植性问题，代码复用，动态连接库的使用的相关电子书。

head文件名不变，内容做了改变？改其他东西无所谓，比如加个函数什么的，但是把以前的函数声明改了，是不可能编译的，就像bin需要getA(),你把getA改成getB，当然会提示找不到getA了。如果你不改变getA的声明，而是改getA的代码，这样怎么改都无所谓了,而且bin也不需要编译，直接调用getA好了，因为bin只认接口,这样bin还是可以运行的。(这就是用动态库的一大好处！修改部分不需要编译整个工程！)


但是会使某些bin去皮之后发生了"段错误"~~看来这个过程并不是安全的~~~

再提个问题：因为编译问题（gcc版本和优化选项等问题，其他因素暂不考虑）会导致一个平台编译的libsome.so.2和另一个平台的libsome.so.2会不同，那么如果一个包包含libsome.so.2就会和系统的libsome.so.2冲突(confilct with file from...)。如果直接使用--replacefiles 选项安装会不会有问题呢？ 还有，如何打包使rpm不检测这种文件冲突,直接自动覆盖，就像用户输入了--replacefiles一样呢？

欢迎来到 DLL 地狱。

Linux 软件包管理器，有一个功能就是避免这个用的。

应用程序自带的库，应该尽可能放到私有目录里，比如 /usr/share/软件名称-版本号/lib/ 或者 /usr/local/lib/  或者 /opt/local/lib/，也就是说编译时就指定使用这些位置里的库文件。

rpm 不支持企图在打包时实现 rpm 安装阶段不检测这种文件冲突，你应该把是否覆盖的选择权交给用户。你应尽可能避免冲突，而不应该是悄无声息地替换系统文件，如果你实现了这样的操作，那无异于恶意程序。

确保软件的二进制代码能够跨平台运行，不是系统软件打包者要考虑的事，而是应用软件作者和独立二进制代码发布者应该考虑的事。我们没有责任和义务确保从我们系统里拆解下来的部件能够运行于其他系统上，不支持，更不提倡这种移花接木的作法。

试图解决跨平台的技术，我印象中有 autopackage 和 klik 技术，参见：
http://autopackage.org
http://klik.atekon.de

看来我的好心可能害了用户~~~~如果不覆盖系统库的话不是不行，只要系统中保证有这些系统文件就行了，那样也能实现跨发行版安装。关键问题就是linux有那些系统文件是像user32.dll,kernel32.dll那样每个系统都带的呢？
如果不确定带哪些的话，是否有这样的选项，即安装的时候自动跳过已经存在的文件，而不是提示冲突中止安装呢？请高手指点！

关于autopackage,klik我会研究一下，不过rpm还是大部分linux使用的包管理系统，毕竟用的人不多。看看有没有借鉴之处~~谢谢啦！

[quote:fe4af95701="linuxpgy"]看来我的好心可能害了用户~~~~如果不覆盖系统库的话不是不行，只要系统中保证有这些系统文件就行了，那样也能实现跨发行版安装。关键问题就是linux有那些系统文件是像user32.dll,kernel32.dll那样每个系统都带的呢？
如果不确定带哪些的话，是否有这样的选项，即安装的时候自动跳过已经存在的文件，而不是提示冲突中止安装呢？请高手指点！

关于autopackage,klik我会研究一下，不过rpm还是大部分linux使用的包管理系统，毕竟用的人不多。看看有没有借鉴之处~~谢谢啦！ [/quote]
即便是系统满足了所有的库，只是文件名相同的话，不在当前系统编译的rpm包安装后也未必正常运行，即相同名字的库因为编译它的环境configure时的参数等等不能替换使用，所以即使你跳过了文件也未必解决问题，这也是为什么不能盲目直接替换文件的原因，各个linux系统文件版本都不同，提供的so名字可能不尽相同，很难说哪个文件是所有系统都带的。

虽然说系统库有相同文件名但是内容不一样，替换可能会导致其他程序有问题，不替换可能导致这个程序不能运行，但是仅仅是可能！有谁能证明一下吗？ 这里引用一下论坛某人(忘了是谁了)的签名：

这句话是没错，但是重复发明轮子和制造永动机都是不应该干的。

我最讨厌的就是重复发明轮子！！不过这和我们讨论的没什么关系吧？

很有关系，因为你在重走 rpm 等包管理曾经走过的路。

是吗？我怎么没听说过？那你举个例子……不要光说好不好啊~~说谁不会~~

对于你来说，库文件不能被替换不符合你的想法。
但这个问题却在所有包管理器里放在首位。

假如windows也是原代码发行,而不是同一份二进制文件的拷贝,大家用的也是在各自的编译环境和参数下编译的话,继续使用windows原始的包管理机制,那会怎样?

Windows 发行版只有一个，所以你携带了自己的 dll 去覆盖系统的 dll 不会导致多大的问题（其实问题也不小，不然不会从 xp 开始，系统给 dll 增加了保护，vista 的保护更严格）。而且因为版本单一，实际系统提供了足够的统一样式的库，不需要还要自己携带很多的库程序。

linux 发行版不同，他们提供的基础库也有出入。

linux的dll就那么脆弱吗？覆盖一个会有问题吗？又不是随便拿个so去替换系统库的，基本可以保证是一份代码编译出来的，理论上不会太大问题，等有问题再解决吧。最近太忙了，都没时间做rpm了~~~