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

zylthinking

比如： 一个程序a链接了b.so, b.so引用了c.so
当连接a的时候， 能够找到b.so, 但找不到c.so
链接程序就罢工不干了。

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

zylthinking@zylthinking:/usr/local/src/v3/source/step1/server/vtdu$ make
g++ -o bin/vtduserver VTDUClient.o CSocket.o regtable.o mem_pool.o dev.o stdafx.o -I.  -L./bin/so -lpthread -lhcnetsdk
/usr/bin/ld: warning: libm4play.so, needed by ./bin/so/libhcnetsdk.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libstdc++.so.5, needed by ./bin/so/libhcnetsdk.so, may conflict with libstdc++.so.6
./bin/so/libhcnetsdk.so: undefined reference to `Hik_PlayM4_GetCurrentFrameNum'
... ...
collect2: ld 返回 1
make: *** [all] 错误 1

libm4play.so和libhcnetsdk.so放在 ./bin/so文件夹下， vtduserver 要声称在 ./bin 下， 其直接引用了 libhcnetsdk.so, 为了链接时能够找到， 使用了 -L./bin/so, -lhcnetsdk, 但链接硬是通不过， 因为找不到 libm4play.so, 因此 libhcnetsdk.so 内部调用的 Hik_PlayM4_GetCurrentFrameNum 等函数找不到， 但我感觉链接 vtduserver 根本没必要寻找 Hik_PlayM4_GetCurrentFrameNum, 这个应该是在生成 libhcnetsdk.so 时的工作。

zylthinking

Parden?

有没有什么办法解决这样的问题， 除了将 libm4play.so 放在 /usr/local/lib 等目录下
而且, 我指定的 -L./bin/so 只能够找到 libhcnetsdk.so, 居然找不到同文件夹下的 libm4play.so
真是郁闷了

zylthinking

zylthinking@zylthinking:~/hk$ g++ --v
使用内建 specs。
目标：i486-linux-gnu
配置为：../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
线程模型：posix
gcc 版本 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

应该和操作系统没关系的吧， 我将LD_LIBRARY_PATH设置好， 或者将其放到 /usr/local/lib等目录自然没问题， 问题是这样前一个麻烦， 后一个就是分开放了， 不能将所有文件都放到一个目录下

zylthinking

但为什么要加呢， 如果 -lm4play 又依赖别的， 别的又依赖别别的 。。。
问题是这个明显是不需要的， 现在就是感觉 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

zylthinking

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

zylthinking

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

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

zylthinking

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

zylthinking

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