linux共享库的运行方式,linux – 为什么以及如何运行某些共享库,就像它们是可执行文件一样？...

在32位Linux系统上,调用它

$/lib/libc.so.6

在64位系统上

$/lib/x86_64-linux-gnu/libc.so.6

在shell中,提供如下输出：

GNU C Library stable release version 2.10.1, by Roland McGrath et al.

Copyright (C) 2009 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE.

Compiled by GNU CC version 4.4.0 20090506 (Red Hat 4.4.0-4).

Compiled on a Linux >>2.6.18-128.4.1.el5<< system on 2009-08-19.

Available extensions:

The C stubs add-on version 2.1.2.

crypt add-on version 2.1 by Michael Glad and others

GNU Libidn by Simon Josefsson

Native POSIX Threads Library by Ulrich Drepper et al

BIND-8.2.3-T5B

RT using linux kernel aio

For bug reporting instructions, please see:

.

为什么以及如何发生这种情况,以及如何在其他共享库中执行相同操作？

我查看了/usr/lib来查找可执行文件,我找到了/usr/lib/libvlc.so.5.5.0.运行它导致了segmentation fault.: – /

解决方法:

该库具有main()函数或等效入口点,并且以这样的方式编译,即它既可用作可执行文件又可用作共享对象.

这是关于如何做到这一点的one suggestion,虽然它对我不起作用.

首先,我们的示例库test.c的源代码：

#include

void sayHello (char *tag) {

printf("%s: Hello!\n", tag);

}

int main (int argc, char *argv[]) {

sayHello(argv[0]);

return 0;

}

编译：

gcc -fPIC -pie -o libtest.so test.c -Wl,-E

在这里,我们正在编译一个共享库(-fPIC),但告诉链接器它是一个常规可执行文件(-pie),并使其符号表可导出(-Wl,-E),以便它可以有效地链接到.

而且,虽然文件会说它是一个共享对象,但它确实可以作为可执行文件使用：

> ./libtest.so

./libtest.so: Hello!

现在我们需要看看它是否真的可以动态链接.一个示例程序,program.c：

#include

extern void sayHello (char*);

int main (int argc, char *argv[]) {

puts("Test program.");

sayHello(argv[0]);

return 0;

}

使用extern节省了我们必须创建标题.现在编译：

gcc program.c -L. -ltest

在我们执行它之前,我们需要为动态加载器添加libtest.so的路径：

export LD_LIBRARY_PATH=./

现在：

> ./a.out

Test program.

./a.out: Hello!

并且ldd a.out将显示与libtest.so的链接.

请注意,我怀疑这是glibc实际编译的方式,因为它可能不像glibc本身那样可移植(请参阅man gcc关于-fPIC和-pie开关),但它演示了基本机制.有关真实细节,您必须查看源makefile.

标签：linux,version,glibc,executable,shared-library

来源： https://codeday.me/bug/20190808/1622359.html