libreadline.so.7：未定义符号：UP答案

【问题标题】：libreadline.so.7: undefined symbol: UPlibreadline.so.7：未定义符号：UP
【发布时间】：2017-10-23 03:34:40
【问题描述】：

在使用 GNU 的 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 的 config.log 中。它几乎就像是一个 Autotools 命令正在生成它，而不是配置测试脚本。

Readline 的 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)

【问题讨论】：

这只是 awk 坏了吗？它自己工作吗？
请注意，符号的状态在 6.3 中也是 U。
@AnttiHaapala - $ gawk --version 返回GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.5, GNU MP 6.1.2)。它似乎没有损坏。
configure 不会直接创建您的 makefile。相反，在执行所有检查后，它会创建一个单独的脚本 config.status，填充模板以创建您的 makefile。这似乎是第二个脚本对您来说失败了，这就是您在日志中看不到任何详细信息的原因。 config.status 的失败非常罕见；我不知道该怎么做，但我自己要做的第一件事就是尝试在config.status 中找到有问题的命令。
请特别注意，当config.status 运行它时，您的错误消息似乎表明gawk 确实使用/usr/local/lib64 中的库。这有点令人惊讶，但似乎是合理的。您当然可以说服它自己这样做，例如使用LD_LIBRARY_PATH，并尝试以这种方式重现错误可能是一件有用的事情。

标签： c shared-libraries readline autotools

【解决方案1】：

怎么了？

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

包 readline 需要 curses。 ncurses 是“新诅咒”。

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

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

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

【讨论】：

您可能忽略了 OP 自己已经回答了这个问题 - 并且差不多三年前就已经回答了。此外，他们对问题的描述与您的明显结论不同。而且他们的启动更合理，因为无论 ncurses 定义什么符号，libreadline 在实践中都不依赖于该库，而且它似乎也不太可能这样做。
OP 已经指出在 libreadline.so 中，符号 UP 是未定义的。 libncurses 定义了符号 UP，安装 libncurses 为我修复了 rlwrap 和 python3 编译问题。因此我得出结论，libreadline 依赖于 libncurses。

【解决方案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 在 cmets 中进行了观察，但由于 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 中完成的，这是规范文件应用的第二个补丁。

【讨论】：

请注意，Linux 确实支持 rpath，就像其他基于 ELF 的系统一样。然而，避免使用它是一个明确的 Fedora 策略问题，因为它阻碍了动态链接器的一般配置选项。您通过在与标准系统二进制文件冲突的动态链接器的搜索路径中安装共享库引起了意外行为。我将此描述为系统管理错误（可以肯定的是，Fedora 可能比其他一些系统更开放）。您可以通过将构建的库放在其他地方来避免它。

【解决方案3】：

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

【讨论】：