Question

Here写道curlftpfs由于最新libcurl3-gnutls中的错误而非常慢。由于此程序包具有较大的反向依赖性（可通过apt-cache showpkg libcurl3-gnutls:amd64或apt-cache rdepends libcurl3-gnutls:amd64验证），因此不建议降级。所以我决定以不同的方式降级它。我已检查存储库中的可用版本：

$ apt-cache policy libcurl3-gnutls:amd64
libcurl3-gnutls:
  Installed: 7.43.0-1ubuntu2.1
  Candidate: 7.43.0-1ubuntu2.1
  Version table:
 *** 7.43.0-1ubuntu2.1 0
        500 http://sk.archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ wily-security/main amd64 Packages
        100 /var/lib/dpkg/status
     7.43.0-1ubuntu2 0
        500 http://sk.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages

然后我下载并提取旧版本而不是已安装版本：

$ apt-get install -d libcurl3-gnutls=7.43.0-1ubuntu2
$ sudo mv /var/cache/apt/archives/libcurl3-gnutls_7.43.0-1ubuntu2_amd64.deb .
$ dpkg -x libcurl3-gnutls_7.43.0-1ubuntu2_amd64.deb  extracted_deb

然后我已经备份了原始二进制文件并在共享库中搜索了一些常用名称：

$ cp $(which curlftpfs) .
$ ldd ./curlftpfs | grep curl
        libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007fcac4443000)

$ readelf -d ./curlftpfs  | grep -i curl
 0x0000000000000001 (NEEDED)             Shared library: [libcurl-gnutls.so.4]

以下步骤只是证明链接文件完全属于libcurl3-gnutls包，且curlftpfs取决于libcurl3-gnutls：

$ dpkg -S /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
libcurl3-gnutls:amd64: /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4

$ apt-cache depends curlftpfs
curlftpfs
  Depends: libc6
  Depends: libcurl3-gnutls
  Depends: libfuse2
  Depends: libglib2.0-0
  Depends: fuse
  Conflicts: curlftpfs:i386

此外，提取和安装的libcurl3-gnutls包的内容似乎完全相同：

$ dpkg -L libcurl3-gnutls:amd64 | sort
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.3
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0
/usr/share
/usr/share/doc
/usr/share/doc/libcurl3-gnutls
/usr/share/doc/libcurl3-gnutls/changelog.Debian.gz
/usr/share/doc/libcurl3-gnutls/copyright
/usr/share/doc/libcurl3-gnutls/NEWS.Debian.gz
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libcurl3-gnutls

$ find extracted_deb/ | sort
extracted/
extracted/usr
extracted/usr/lib
extracted/usr/lib/x86_64-linux-gnu
extracted/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.3
extracted/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
extracted/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0
extracted/usr/share
extracted/usr/share/doc
extracted/usr/share/doc/libcurl3-gnutls
extracted/usr/share/doc/libcurl3-gnutls/changelog.Debian.gz
extracted/usr/share/doc/libcurl3-gnutls/copyright
extracted/usr/share/doc/libcurl3-gnutls/NEWS.Debian.gz
extracted/usr/share/lintian
extracted/usr/share/lintian/overrides
extracted/usr/share/lintian/overrides/libcurl3-gnutls

我的问题是如何重写ldd输出中包含的路径并将其指向我提取的文件？我已经阅读了关于rpath和patchelf以及chrpath here和here但我想这不是我的情况，因为以下命令不会返回任何有用信息：

$ readelf -d ./curlftpfs | grep -i rpath
$
$ chrpath -l ./curlftpfs
./curlftpfs: no rpath or runpath tag found.
$
$ patchelf --print-rpath ./curlftpfs
$

所以似乎没有使用rpath。我还读过$LD_LIBRARY_PRELOAD，但我想它会改变给定二进制文件的所有共享库的路径而不仅仅是一个特定的（在我的情况下是/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4）所以我需要有整个树图书馆。 There也是建议更改加载程序的解决方案（在我的示例/lib64/ld-linux-x86-64.so.2中我猜）：

$ patchelf --print-interpreter ./curlftpfs 
/lib64/ld-linux-x86-64.so.2
$
$ ldd ./curlftpfs | grep ld-linux
    /lib64/ld-linux-x86-64.so.2 (0x0000564966b64000)
$
$ ls -laL /lib/x86_64-linux-gnu/ld-2.21.so
-rwxr-xr-x 1 root root 154376 Mar 26  2015 /lib/x86_64-linux-gnu/ld-2.21.so

但说实话，我没有明白这一点。你能帮忙吗？

Answer 1

我的问题是如何重写ldd中包含的路径输出并将其指向我提取的文件？

看起来你想要的是覆盖旧版本的libcurl-gnutls.so库的功能。正如您在上一个链接中所暗示的那样，您可以使用LD_PRELOAD环境变量来覆盖标准库函数。

假设您手动安装（降级）的libcurl-gnutls版本具有动态库文件/usr/local/lib/libcurl-gnutls.so.4.4.0。然后，您可以执行以下操作： LD_PRELOAD=/usr/local/lib/libcurl-gnutls.so.4.4.0 curlftpfs [some_arguments...]

别忘了/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4和/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.3只是象征性的链接到libcurl-gnutls的主库文件。复制这些符号链接可能不会产生预期的效果。你需要长命名的SO文件，比如libcurl-gnutls.so.4.4.0。

额外备注

您可以通过执行以下操作来测试此覆盖是否有效： LD_PRELOAD=/usr/local/lib/libcurl-gnutls.so.4.4.0 ldd $(which curlftpfs)

对于手动安装，/ usr / local / lib可能不是放置您不想干扰其他二进制文件的动态库的好地方。这是因为/etc/ld.so.conf.d/libc.conf可能指向/ usr / local / lib以获取自动库。（我的Debian机器确实如此）

要查看LD_环境变量的定义，请查看ld.so(8)手册页（man ld.so）。

以可执行二进制文件更改一个特定共享库

1 个答案:

额外备注