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=.