GNU链接程序： 这算不算狗拿耗子

MMMIX

原帖由 zylthinking 于 2007-12-13 19:20 发表
但为什么要加呢， 如果 -lm4play 又依赖别的， 别的又依赖别别的 。。。
问题是这个明显是不需要的， 现在就是感觉 linker 多管闲事

建议了解下 linker 的工作原理，以及动态/静态链接的原理。

zylthinking

我不用去了解， 你是不是再说windows违反了linker 的工作原理，以及动态/静态链接的原理?

[ 本帖最后由 zylthinking 于 2007-12-14 13:51 编辑 ]

zylthinking

要说链接原理， 我是没学过正式理论， 但想来应该是这样的吧：
1。 似乎有个名词叫符号表， 编译时未解决的符号被标记
2。 链接程序会在其他编译单元寻找， 或so或dll中, so 通过 -lpthread等参数传递给linker以指示可以在哪里寻找符号, windows下通过 .lib文件指示
3. 如果寻找到了， 则链接成功, 将外部引用的符号填入可执行文件一个section中， （windows下）， linux下不知道， 估计也差不多吧， 一并填入的包括所引用的函数在目标so, dll中的位置。
4。 程序运行时， 加载so, dll到用户空间， 而后根据so, dll加载的内存地址修改所引用函数的位置到其在内存中的位置， 似乎这一步叫什么重定位

然后， 就可以运行了

如果我的理解是正确的， 那么如果应用程序 a 直接调用了 b.so中的函数， 则其链接时， 所要解决的只是b.so 中的函数在b.so中的位置， 只要能够找到该信息， 就应该链接成功， 至于b.so调用了c.so 中的函数， 那不关a的事。

如果我的理解错了， 那请说出错在哪里。 而且请说出如果按照我以上的步骤进行链接， 有什么问题解决不了， 以致于所谓 linker 的工作原理，以及动态/静态链接的原理 明确规定要链接成功a, linker 必须找到 c.so

MMMIX

如果你的系统中根本没有 b.so 依赖的 c.so, 那么这么链接出来的程序能执行么？不能执行的话你准备抱怨什么？linker 不作为？

[ 本帖最后由 MMMIX 于 2007-12-16 16:50 编辑 ]

zylthinking

能不能运行是另外一回事啊
而且也不是b.so依赖a, 是 a依赖b.so, b.so依赖c.so, c.so找不到

MMMIX

原帖由 zylthinking 于 2007-12-15 15:40 发表
能不能运行是另外一回事啊

如果一个 linker 生成的可执行文件如果不能执行，我估计抱怨的人会更多。。。

而且也不是b.so依赖a, 是 a依赖b.so, b.so依赖c.so, c.so找不到

嗯，输入的时候手误。

zylthinking

你要是纠缠那个让人抱怨， 就不说了。
现在问题是c.so找不到为什么不让链接成功， 莫非就是怕人抱怨？

[ 本帖最后由 zylthinking 于 2007-12-16 19:15 编辑 ]

MMMIX

原帖由 zylthinking 于 2007-12-16 19:13 发表
现在问题是c.so找不到为什么不让链接成功，

c.so 找不到为什么要让链接成功？谁说链接时的符号绑定(tie up)不能是递归的？

我倒是感觉这纯粹是多管闲事了， 因为理论上链接的时候c.so和a没有关系的

恰恰相反，不论是理论上还是实际上，c.so 和 a 都是有关系的。

zylthinking

不论是理论上还是实际上. windows就是不需要的， 除非你能解释微软为什么能够做到
说链接时的符号绑定(tie up)不能是递归的：  谁说一定要递归的？ 为什么要递归， 你先说明一下不递归的话能不能做到, just yes or no

zylthinking

你是不是倾向于调用了 dlopen 等函数的程序在编译的时候也一定要该so存在? 如果该so的名字不巧正好位于一个配置文件， 那你就挂了， 永远也别想连接成功， 因为linker保证不了若干年后某个人将里面的名字改掉， 它决定不了这个名字， 就永远不让链接是不是