动态连接库问题

["Vern Sun" <s5unty@gmail.com>]

在作一个基于d-i的安装程序，运行这个安装程序时发现一个问题，搞了两天没什么头绪。问题是出自这样一个错误信息：
>debconf: relocation error: /usr/lib/librays-partitioner-gtk.so.0: symbol msgget, version GLIBC_2.0 not defined in file libc.so.6 with link time reference.

检查打好的udeb
$ dpkg -x rays-partitioner-gtk-plugin_0.1.1_i386.udeb .
$ readelf -a ./usr/lib/librays-partitioner-gtk.so | grep msgget; echo $?
000355b0  0000fd07 R_386_JUMP_SLOT   00000000   msgget
   253: 00000000    78 FUNC    GLOBAL DEFAULT  UND 
msgget@GLIBC_2.0 (2)
0
$ ldd ./usr/lib/librays-partitioner-gtk.so
    ...
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7769000)
$ readelf -a /lib/tls/i686/cmov/libc.so.6 | grep msgget; echo $?
  2093: 000cca40   102 FUNC    GLOBAL DEFAULT   11 msgget@@GLIBC_2.0
0

检查手工编译生成的库
$ ./configure --prefix=/tmp/partitioner && make && make install
$ cd /tmp/partitioner
$ readelf -a librays-partitioner-gtk.so | grep msgget; echo $?
00030804  0000f907 R_386_JUMP_SLOT   00000000   msgget
   249: 00000000    78 FUNC    GLOBAL DEFAULT  UND msgget@GLIBC_2.0 (2)
   422: 00000000    78 FUNC    GLOBAL DEFAULT  UND msgget@@GLIBC_2.0
0

手工编译生成的库及程序，经过测试是正常的。然而安装程序使用的是从udeb包中解压的库及程序，经过测试是有问题的(上面的错误日志)。通过比较两种不同方式创建的库，发现来自udeb包的库比来自手工编译的库少了一个msgget@@GLIBC_2.0，我不知道这算不算问题。

另外要说明的是，我还有一个程序rays-partitioner-init也调用了msgget，它和librays-partitioner-gtk.so是同一个source打出的两个udeb包，在librays-partitioner-gtk.so之前使用。奇怪的是调用msgget时，程序rays-partitioner-init没有遇到问题，而动态链接库librays-partitioner-gtk.so却被告知有问题。

只google到一个解决办法
设置环境变量export LD_ASSUME_KERNEL=2.4.1，但是没有效果。

如果有谁能帮我把上面的内容翻译成english，我异常感谢！