动态so生成以及调用

vi hello.c //要生成的动态库文件名、

#include <stdio.h>

int fun(char *c)

{

    printf("%s\n",c);

}

vi callso.c//要调用动态库的文件

int main()

{

fun("fun is a shared library");

}

vi makefile

CFALGS= -fPIC -shared

all: lib bin

bin:callso

lib:libhello.so

hello.o:hello.c //在执行libhello.so 时会自动生成

    gcc -c $(CFLAGS) -o $@ $? //生成.o 文件。-c 只编译。加入-o可以打印出这一行

libhello.so:hello.o

    gcc $(CFLAGS) -o libhello.so $? //生成so 文件

callso.o:callso.c

    gcc -c -o $@ $? // 

callso.callso.o

    gcc -o $@ $? -L. -lhello 调用so 文件。-L 跟目录,-l 动态库名。

运行程序

尽管我们成功编译了callso可执行文件,但很有可能不能执行。一个可能是权限问题。我们需要有执行该文件的权限,见Linux文件管理背景知识

另一个情况是:

./callso: error while loading shared libraries: libhello.so: cannot open shared object file: No such file or directory

 

这是因为操作系统无法找到库。libmystack.so位于当前路径,位于库文件的默认路径之外。尽管我们在编译时(compile time)提供了.so文件的位置,但这个信息并没有写入test可执行文件(runtime)。可以使用下面命令测试:

$ldd callso

ldd用于显示可执行文件所依赖的库。显示:

    linux-vdso.so.1 =>  (0x00007fff31dff000)
    libhello.so => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fca30de7000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fca311cb000)

这说明callso可执行文件无法找到它所需的libhello.so库文件。

 

为了解决上面的问题,我们可以将.so文件放入默认搜索路径中。但有时,特别是多用户环境下,我们不享有在默认搜索路径写入的权限。

一个解决方案是设置LD_LIBRARY_PATH环境变量。比如:

$export LD_LIBRARY_PATH=.


猜你喜欢

转载自blog.csdn.net/linke_linux/article/details/80493340