Question

在使用GNU＆＃39; Readline 7时，我无法从源代码构建cURL和Git。配置cURL等库时，结果为：

$ ./configure ...
...
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
gawk: symbol lookup error: /usr/local/lib64/libreadline.so.7: undefined symbol: UP
config.status: error: could not create Makefile
Failed to configure cURL

果然：

$ nm -D /usr/local/lib64/libreadline.so | egrep 'UP|DOWN|LEFT|RIGHT'
    U UP

和

$ nm /usr/local/lib64/libreadline.a | egrep 'UP|DOWN|LEFT|RIGHT'
    U UP

现在，奇怪的是，消息gawk: symbol lookup error: /usr/local/lib64/libreadline.so.7: undefined symbol: UP和undefined symbol: UP 消息显示在cURL＆＃39; config.log中。它几乎就像一个Autotools命令正在生成它，而不是配置测试脚本。

Readline＆＃39; CHANGE日志和README不会讨论更改或丢失的符号。我发现其他用户遇到同样问题的几个帖子，但修复程序通常退化为，降级到readline 6.3。

此时我不确定这是否是Readline问题;或者像cURL或Git这样的程序或库中的问题。因为符号在Readline中是未定义的，所以我认为它更接近Readline问题（或者Readline依赖于库）。

我的第一个问题是，我应该从哪里开始寻找问题？

我的第二个问题是，我们该如何解决？

这是cURL config.log的相关部分。没有尾部也没有测试，因为cURL似乎没有测试它或它没有被记录。甚至日志中也缺少错误字符串。

$ cat curl-7.56.0/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

  $ ./configure --prefix=/usr/local --libdir=/usr/local/lib64 --enable-shared --
enable-static --enable-optimize --enable-symbol-hiding --enable-http --enable-ft
p --enable-file --enable-ldap --enable-ldaps --enable-rtsp --enable-proxy --enab
le-dict --enable-telnet --enable-tftp --enable-pop3 --enable-imap --enable-smb -
-enable-smtp --enable-gopher --enable-cookies --enable-ipv6 --with-zlib=/usr/loc
al --with-ssl=/usr/local --without-gnutls --without-polarssl --without-mbedtls -
-without-cyassl --without-nss --without-libssh2 --with-libidn2=/usr/local --with
-nghttp2 --with-ca-path=/etc/ssl/certs/ --with-ca-bundle=/etc/ssl/certs/ca-bundl
e.crt

...

为了完整起见，我没有从源代码构建awk，gawk或mawk并在某处安装它们。 gawk是Fedora 26的标准版，它不使用/usr/local/lib64中的库：

Build-Scripts$ command -v gawk
/bin/gawk

Build-Scripts$ ldd /bin/gawk
    linux-vdso.so.1 (0x00007ffc33d2d000)
    libsigsegv.so.2 => /lib64/libsigsegv.so.2 (0x00007f3da9135000)
    libreadline.so.7 => /lib64/libreadline.so.7 (0x00007f3da8ee9000)
    libmpfr.so.4 => /lib64/libmpfr.so.4 (0x00007f3da8c87000)
    libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f3da8a10000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f3da880c000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f3da84f6000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f3da8125000)
    libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f3da7ef9000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f3da95e0000)

Answer 1

怎么了？

符号UP在lib_termcap.c和lib_termcap.o中定义在库libncurses.so和libncurses.a中在ncurses包中

包裹阅读热线需要诅咒。 ncurses是“新诅咒”。

$ nm -D lib/libncurses.so | grep -w UP
000000000025f6c8 B UP

您必须使用--with-shared来编译共享库。

./configure --prefix=/u01/sw --with-shared
make

Answer 2

看来有两个问题。首先，动态链接器选择了错误的库。也就是说，运行时链接器错误地猜到了/usr/bin/gawk被授权使用/usr/local/lib64/libreadline.so。就我而言，/usr/local充满了更新，它在某种程度上是一个游乐场。 /usr个程序只应使用/lib64和/usr/lib64中的库;和/usr/local程序可以使用/lib64，/usr/lib64和/usr/local/lib64中的库。它们永远不应混合，但我们无法向链接器表达策略。

动态链接器vulnerability has festered for years和Linux是我所知道的唯一仍然没有解决它的主要操作系统。 OS X有安装名称，Windows有清单，BSD在构建时设置了rpath ...

其次，makefile需要修补。 @AnttiHaapala和@JohnBollinger在评论中发表了观察，但我正在努力与＃34;它应该工作＆＃34;因为Red Hat和Fedora是主要的发行版。看来事情根本就是未经测试，结果是休息。

要清除Fedora的问题，应该在解压缩tarball并配置库之后完成：

for mfile in $(find "$PWD" -name 'Makefile'); do
    sed -i 's|SHLIB_LIBS =|SHLIB_LIBS = -ltinfo|g' "$mfile"
done

事情开始按预期工作后，我觉得Fedora必须做同样的事情，但我没有在Fedora的readline.spec中看到它。但是它是在readline-7.0-shlib.patch中完成的，这是spec文件适用的第二个补丁。

Answer 3

看来，在最近的 ncurses 版本中，UP（和相关）符号已移至 libtinfo，默认情况下 ncurses 不会构建。如果您将 --with-termlib 标志传递给 ncurses (./configure --with-shared --with-termlib)，它将构建此库并且符号应该解析。值得注意的是，不要遵循 jww 先前回答中的建议很重要，因为该补丁将明确避免链接 libtinfo。

libreadline.so.7：未定义的符号：UP

3 个答案: