在共享库的构建选项中添加“-rpath,/usr/lib”会导致段错误答案

【问题标题】：adding "-rpath,/usr/lib" in the build options of a shared library cause a segfault在共享库的构建选项中添加“-rpath,/usr/lib”会导致段错误
【发布时间】：2013-10-19 14:35:07
【问题描述】：

我有一个 hello world 程序。

#include <stdio.h>
#include <stdlib.h>

int main()
{
    printf("hello world! \n");
    return 0;
}

我在链接阶段的程序构建中添加-lmicroxml，以便链接到库libmicroxml.so

当我启动我的程序时，我遇到了分段错误。分段错误与libmicroxml.so 的负载有关。在我的 helloo world 程序执行之后在这里：

 strace ./test
execve("./test", ["./test"], [/* 11 vars */]) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x777de000
stat("/etc/ld.so.cache", 0x7f944760)    = -1 ENOENT (No such file or directory)
open("/lib/libmicroxml.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libmicroxml.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libmicroxml.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=4129, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x777dd000
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\4p\0\0\0004"..., 4096) = 4096
old_mmap(NULL, 69632, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x777b3000
old_mmap(0x777b3000, 1572, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x777b3000
old_mmap(0x777c3000, 1648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x777c3000
close(3)                                = 0
munmap(0x777dd000, 4096)                = 0
open("/lib/libgcc_s.so.1", O_RDONLY)    = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=78232, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x777dd000
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0006\320\0\0\0004"..., 4096) = 4096
old_mmap(NULL, 147456, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7778f000
old_mmap(0x7778f000, 76928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7778f000
old_mmap(0x777b2000, 408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x13000) = 0x777b2000
close(3)                                = 0
munmap(0x777dd000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=413076, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x777dd000
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\253`\0\0\0004"..., 4096) = 4096
old_mmap(NULL, 503808, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77714000
old_mmap(0x77714000, 405592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x77714000
old_mmap(0x77787000, 7572, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x63000) = 0x77787000
old_mmap(0x77789000, 21036, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x77789000
close(3)                                = 0
munmap(0x777dd000, 4096)                = 0
open("/usr/lib/libgcc_s.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=169712, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x777dd000
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\307\220\0\0\0004"..., 4096) = 4096
old_mmap(NULL, 237568, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x776da000
old_mmap(0x776da000, 169036, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x776da000
old_mmap(0x77713000, 1776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x29000) = 0x77713000
close(3)                                = 0
munmap(0x777dd000, 4096)                = 0
open("/usr/lib/libc.so.0", O_RDONLY)    = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=425968, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x777dd000
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\267`\0\0\0004"..., 4096) = 4096
old_mmap(NULL, 516096, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7765c000
old_mmap(0x7765c000, 418924, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7765c000
old_mmap(0x776d2000, 8176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x66000) = 0x776d2000
old_mmap(0x776d4000, 21784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x776d4000
close(3)                                = 0
munmap(0x777dd000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=413076, ...}) = 0
close(3)                                = 0
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=28976, ...}) = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=413076, ...}) = 0
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x777dd000
set_thread_area(0x777e4440)             = 0
mprotect(0x77787000, 4096, PROT_READ)   = 0
mprotect(0x776d2000, 4096, PROT_READ)   = 0
mprotect(0x777da000, 4096, PROT_READ)   = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

在构建 libmicroxml 库时，我发现他们在构建库时使用了DSOFLAGS=-Wl,-soname,libmicroxml.so.1,-rpath,/usr/lib -shared -fPIC（在链接阶段）。

我从选项中删除了-rpath,/usr/lib，所以新选项是DSOFLAGS=-Wl,-soname,libmicroxml.so.1 -shared -fPIC

然后我重建库，然后我启动了 hello world 程序和分段错误消失。

我正在使用mips_gcc-4.6-linaro_uClibc-0.9.33.2 构建

我的旧 gcc mips_gcc-4.3.3+cs_uClibc-0.9.30.1 没有重现此问题

谁能解释为什么从链接选项中删除 -rpath,/usr/lib 会修复库加载中的段错误？

【问题讨论】：

<pedantic> main 不返回 int </pedantic>
@Kninnug 这不是我的问题的原因。我以任何方式添加返回到我的主函数
在你的电脑上“locate libmicroxml.so”的输出是什么？
@MOHAMED 确保如果您指定 -rpath,/usr/lib 有文件或库要从那里加载并且文件存在，stackoverflow.com/questions/6562403/…（突尼斯和平与繁荣）

标签： c linux gcc shared-libraries strace

【解决方案1】：

从跟踪看来，您的程序加载了相同模块的不同二进制文件，它们应该是相同的版本：

/lib/libc.so.0（大小：413076 字节）vs. /usr/lib/libc.so.0（大小：425968 字节）。

/lib/libgcc_s.so.1（大小：78232 字节）vs. /usr/lib/libgcc_s.so.1（大小：169712 字节）。

这可能是因为当您在模块链接中使用-rpath 时，您强制它从/usr/lib 加载模块，但您的程序使用的默认搜索路径是/lib（根据dlopen 文档http://tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html)。

所以：您的程序加载了/usr/lib/libmicroxml.so.1（请注意，它找不到/lib/libmicroxml.so.1，尽管它首先搜索了此路径）。然后它继续从/lib 加载它需要的模块（libgcc 和libc），最后，因为libmicroxml 需要从/usr/lib 加载这些模块（因为提供了构建参数），它们也是从此路径加载。

一旦您将两个具有相同名称和接口的不同库（因为它们属于同一版本）加载在一起，您就无法知道调用了哪个函数的哪个版本，这可能会导致不一致。

我想你可以按照你的方式解决这个问题，或者在你的程序构建中添加相同的 -rpath 参数。

删除-rpath解决这个问题的原因是在加载libmicroxml所需的模块时，加载器首先搜索/lib作为默认的第一个目录（因为没有指定其他目录），并且由于模块在此文件夹已加载，没有冲突。

无论如何，在同一个驱动器上为同一个模块具有相同版本的两个不同二进制文件的情况是非常不健康的。

至于 GCC 版本，我只能假设正确的 libc 或 libgcc 与以前的 GCC 一起使用（甚至安装），并被更新的 GCC 替换，但我找不到支持这一点的文档。

【讨论】：

【解决方案2】：

您的 DSOFLAGS 如下所示：

DSOFLAGS=-Wl,-soname,libmicroxml.so.1,-rpath,/usr/lib -shared -fPIC

你试过这样编译吗？

gcc -L/usr/lib -Wl,-rpath=/usr/lib -Wall -o test main.c -lmicroxml

然后，您可以在 Makefile 中使用这一行以及 CC 和 CFLAGS 来简化编译，如果您能够以这种方式编译它。还有其他几种链接方式。

this 链接上的好信息。

【讨论】：