神秘的共享库不会链接到应用程序 [英] Shared library mysteriously doesn't get linked to application

问题描述

我有一个共享库（libhoard.so），我试图用一个简单的测试二进制文件链接。但是，根据我在共享库上编译的机器不会显示在测试二进制文件中。我不确定机器上有什么区别，也是我问这个问题的部分原因。 我很好奇我能做什么来解决为什么共享库不会显示在破损机器上的测试二进制文件中？

< hr>

我使用这个命令来编译二进制文件（libhoard.so在同一个目录中）：

  $ g ++ -L。 -lhoard hoard_test.o 
  

损坏的机器：

  $ ldd a.out 
 linux-gate.so.1 => （0x00858000）
 libstdc ++。so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6（0x004dc000）
 libc.so.6 => /lib/i386-linux-gnu/libc.so.6（0x00aaf000）
 libm.so.6 => /lib/i386-linux-gnu/libm.so.6（0x00675000）
 /lib/ld-linux.so.2（0x00d18000）
 libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1（0x0040d000）
  

工作机器：

  $ ldd a.out 
 linux-gate.so.1 => （0x00110000）
 libhoard.so（0x00111000）< -----------------有它！ 
 libstdc ++。so.6 => /usr/lib/libstdc++.so.6（0x03ba8000）
 libm.so.6 => /lib/libm.so.6（0x007a9000）
 libgcc_s.so.1 => /lib/libgcc_s.so.1（0x00bf7000）
 libc.so.6 => /lib/libc.so.6（0x0063e000）
 libdl.so.2 => /lib/libdl.so.2（0x007d4000）
 libpthread.so.0 => /lib/libpthread.so.0（0x007db000）
 /lib/ld-linux.so.2（0x0061e000）
  

---

以下是一些随机版本信息：

破碎的机器：

  $ uname -srv 
 Linux 2.6.38-11-generic＃50-Ubuntu SMP Mon Sep 12 21:18:14 UTC 2011 
 $ g ++ --version 
 g ++（Ubuntu / Linaro 4.6.1-9ubuntu3）4.6.1 
  

工作机器：

  $ uname -srv 
 Linux 2.6.25.3-18.fc9.i686＃ 1 SMP Tue May 5 05:38:53 EDT 2008 
 $ g ++ --version 
 g ++（GCC）4.3.0 20080428（Red Hat 4.3.0-8）
  

解决方案

tl; dr版本：添加 -Wl， - 不需要到链接命令

经过与OP的一系列实验和对话后，在最新版本的Ubuntu中， ld 使用 - 缺省需要。这样做是为了移除对明确不需要的库的引用。

Hoard的工作方式是 LD_PRELOAD 库。即，您不需要直接在 libhoard.so 中使用函数。当然，如果你想......除非 - 根据需要，你可以直接链接 libhoard 当然，使用code>。



发现这个之后，解决方案很简单。只需在 gcc 链接命令中添加 -Wl， - 不需要。

I have a shared library (libhoard.so) that I'm trying to link with a simple test binary. However, depending on the machine I compile on the shared library doesn't show up in the test binary. I'm not sure what differences exist on the machines and is partly why I'm asking the question. I'm curious what I can do to troubleshoot why the shared library doesn't show up on the test binary on the "broken" machine?

---

I used this command to compile both binaries (libhoard.so is in the same directory):

$ g++ -L. -lhoard hoard_test.o 

Broken machine:

$ ldd a.out 
  linux-gate.so.1 =>  (0x00858000)
  libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x004dc000)
  libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00aaf000)
  libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x00675000)
  /lib/ld-linux.so.2 (0x00d18000)
  libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x0040d000)

Working machine:

$ ldd a.out 
  linux-gate.so.1 =>  (0x00110000)
  libhoard.so (0x00111000) <----------------- THERE IT IS!
  libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x03ba8000)
  libm.so.6 => /lib/libm.so.6 (0x007a9000)
  libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00bf7000)
  libc.so.6 => /lib/libc.so.6 (0x0063e000)
  libdl.so.2 => /lib/libdl.so.2 (0x007d4000)
  libpthread.so.0 => /lib/libpthread.so.0 (0x007db000)
  /lib/ld-linux.so.2 (0x0061e000)

---

Here is some random version information:

Broken machine:

$ uname -srv
Linux 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC 2011
$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1

Working machine:

$ uname -srv
Linux 2.6.25.3-18.fc9.i686 #1 SMP Tue May 13 05:38:53 EDT 2008
$ g++ --version
g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)

解决方案

tl;dr version: Add -Wl,--no-as-needed to the link command.

After a series of experimentation and conversations with the OP, I've figured out what's going on.

In the latest version of Ubuntu, ld uses --as-needed by default. What that does is to remove references to libraries that are not explicitly required.

The way Hoard works is as an LD_PRELOAD library. i.e., you are not supposed to need to use functions in libhoard.so directly. Of course, you could link in libhoard directly if you wanted to...unless --as-needed is used, of course.

After discovering this, the solution is simple. Just add -Wl,--no-as-needed to the gcc linking command.

这篇关于神秘的共享库不会链接到应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！