在作一个基于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 [EMAIL PROTECTED] (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 [EMAIL PROTECTED] (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，我异常感谢！
