共享库如何在混合的64位/32位系统中工作?

Good morning,

早上好,

on a 64bit RedHat box we have to compile and run a 32bit application. Meanwhile I managed to compile the gcc version needed (4.0.3) and all required runtime libraries in 32bit and have set the LD_LIBRARY_PATH to point to the 32bit versions, but now during the remaining build process, a small java program needs to be executed which is installed in /usr/bin as a 64bit program, which now finds the 32bit version of libgcc_s.so first.

在一个64位的红帽框上，我们必须编译并运行一个32位的应用程序。同时我设法编译所需的gcc版本(4.0.3)和所有必需的32位运行时库,并将LD_LIBRARY_PATH设置为指向32位版本,但是现在剩下的构建过程中,一个小的java程序需要执行安装的工作作为一个64位的程序,目前发现libgcc_s的32位版本。首先。

In general, if I set the LD_LIBRARY_PATH to the 32bit versions, I break the 64bit programs and vice versa.

通常，如果我将LD_LIBRARY_PATH设置为32位版本，我将破坏64位程序，反之亦然。

How it this supposed to work at all? I am certain I am not the first person with this problem at hand. How is it solved usually?

这是怎么回事?我确信我不是第一个手头有这个问题的人。它通常是如何解决的?

Regards, Stefan

问候,斯蒂芬

5 个解决方案

#1

Add both the 32-bit and 64-bit directories to the LD_LIBRARY_PATH.

将32位和64位目录都添加到LD_LIBRARY_PATH。

If you do this, then the ld.so for 32-bit or 64-bit will use the correct libraries.

如果您这样做，那么对于32位或64位，ld.so将使用正确的库。

e.g. A 32-bit test app "test32" and 64-bit test app "test", with a locally-installed copy of a (newer version of) gcc and binutils in a user homedir, to avoid clobbering the system-wide install of gcc:

例如，一个32位测试应用程序“test32”和64位测试应用程序“test”，在用户homedir中安装一个本地安装的gcc和binutils(较新的版本)，以避免阻塞gcc在系统范围内的安装:

=> export LD_LIBRARY_PATH=/home/user1/pub/gcc+binutils/lib:/home/user1/pub/gcc+binutils/lib64

=> ldd ./test32
    libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib/libstdc++.so.6 (0x00111000)
    libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib/libgcc_s.so.1 (0x00221000)

=> ldd ./test
    libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib64/libstdc++.so.6 (0x00007ffff7cfc000)
    libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib64/libgcc_s.so.1 (0x00007ffff7ad2000)

(Less interesting library paths removed)

(删除不太有趣的库路径)

This shows that the loaders know to ignore the libraries of the wrong architecture, at least on this Scientific Linux 6.3 (RHEL-derived) system. I would expect other distros to work similarly, but haven't tested this.

这表明加载程序知道忽略错误架构的库，至少在这个科学的Linux 6.3 (rhl -派生)系统上是这样的。我希望其他发行版也能起到类似的作用，但还没有对此进行测试。

This may have only started being the case more recently than your (unspecified) distro version, however.

不过，这种情况可能只是最近才开始出现的，而不是您的发行版(未指定)。

#2

On Solaris one can use LD_LIBRARY32_PATH and LD_LIBRARY64_PATH, but that isn't supported on Linux.

在Solaris中，可以使用LD_LIBRARY32_PATH和LD_LIBRARY64_PATH，但Linux不支持这种方式。

In general, you should just never need to set LD_LIBRARY_PATH at all in the first place:

通常，您根本不需要设置LD_LIBRARY_PATH:

either install needed libraries into /usr/lib32 or /usr/lib64 as appropriate, or
要么将需要的库安装到/usr/lib32或/usr/lib64中，要么。
build your 32-bit application with -Wl,-rpath=/path/to/32-bit/libs
使用-Wl、-rpath=/path/to/32位/libs构建您的32位应用程序

#3

As a workaround, wrap the Java call in a small shell script which unsets LD_LIBRARY_PATH and then calls the executable. Alternatively, this might also work:

作为一种解决方案，将Java调用包装在一个小shell脚本中，该脚本解除LD_LIBRARY_PATH的设置，然后调用可执行文件。或者，这也可能起作用:

LD_LIBRARY_PATH= java...

Note the space between "=" and the name of the executable.

注意“=”和可执行文件的名称之间的空格。

#4

Just set LD_LIBRARY_PATH to both paths (use colons to delimit). The linker will ignore the libraries that it cannot read.

只需将LD_LIBRARY_PATH设置为两条路径(使用冒号分隔)。链接器将忽略它不能读取的库。

#5

I have faced this exact same problem when remastering a 32bit tinycore64 system running a 64bit kernel.

当重新控制运行64位内核的32位tinycore64系统时，我遇到了同样的问题。

After much searching, I have discovered why these comments would make sense to both of them.

经过大量的搜索，我发现了为什么这些评论对他们都是有意义的。

"That would be nice, but - at least in my environment - it did not appear to work. The loader did complain; it did not simply skip the libraries that do not match the bit-ness. Sadly!" - struppi

“那太好了，但是——至少在我的环境中——这似乎行不通。”加载程序并抱怨;它不仅仅跳过不匹配位的库。遗憾的是!”——struppi

"This is very strange, could you describe how things failed? Also, perhaps post the output of ldd?" - Adam Goode

“这很奇怪，你能描述一下事情是如何失败的吗?”还有，也许发布ldd的输出?——亚当•古德

And why this comment might appear to be true but is actually incorrect.

为什么这个评论看起来是对的，实际上是错的。

The linker will ignore the libraries that it cannot read.

链接器将忽略它不能读取的库。

This link shed's some light on it. http://www.markusbe.com/2009/09/about-running-32-bit-programs-on-64-bit-ubuntu-and-shared-libraries/

这个链接棚有一些线索。http://www.markusbe.com/2009/09/about -运行- 32位程序- 64位ubuntu -和-共享- libraries/

And more to the point, you will find the ld.so manpage enlightening.

更重要的是，你会发现ld。所以手册很有启发性。

It turns out the path name can make a difference in what the runtime linker ld.so chooses as the library to load. On my 64bit linux system I have a range of odd directory names in addition to the standard ones. e.g. /lib/x86_64-linux-gnu. I actually thought I'd experiment by moving the libraries in that path to /lib64. When I did that, guess what happened? suddenly my 64bit app (brctl in this case) didn't work and complained with "Wrong ELF class". Hello... now we're onto something.

结果显示路径名可以在运行时链接器ld中产生不同，所以选择作为库加载。在我的64位linux系统中，除了标准目录之外，我还有一系列奇怪的目录名。例如/lib/x86_64-linux-gnu。实际上，我认为我应该尝试将路径中的库移动到/lib64。当我这么做的时候，猜猜发生了什么?突然，我的64位应用(在本例中是brctl)坏了，并抱怨“错误的ELF类”。你好……现在我们到一些东西。

Now I'm not 100% certain but the key seems to be related to rpath token expansion. I suspect the ${PLATFORM} expansion may have something to do with it. And the name x86_64 must be part of that.

现在我不是百分之百的确定，但关键似乎与rpath令牌扩展有关。我怀疑${PLATFORM}扩展可能与它有关。名称x86_64必须是其中的一部分。

In any case, I found when I put my 64-bit libraries in library paths named x86_64-linux-gnu as apposed to just lib64, then they were preferred over the 32bit ones and things worked.

在任何情况下，当我将64位的库放到库路径中，将其命名为x86_64- linuxgnu时，我就会将它们命名为lib64，这样它们就比32位的更受欢迎了。

In your case, you probably want to do something very similar for 32bit libraries on 64. Try i386-linux-gnu.

在您的示例中，您可能希望对64上的32位库执行非常类似的操作。i386-linux-gnu试试。

So in my case where I am installing 64bit shared libraries onto a 32bit userland, I created the following paths:

因此，在我将64位共享库安装到32位用户的情况下，我创建了以下路径:

mkdir /lib/x86_64-linux-gnu/
mkdir /usr/lib/x86_64-linux-gnu/
ln -s /lib/x86_64-linux-gnu /lib64
ln -s /usr/lib/x86_64-linux-gnu /usr/lib64

Add your 64bit libraries to the 64bit paths and 32bit libraries to the 32bit /lib & /usr/lib paths only.

将64位库添加到64位路径中，将32位库添加到32位/lib和/usr/lib路径中。

Then add the 64bit specific paths to ld.so.conf and update your cache with ldconfig Now your 32-bit & 64-bit applications will run seamlessly.

然后将64位特定路径添加到ld.so中。现在，您的32位和64位应用程序将无缝运行。

#1