免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 2149 | 回复: 3

[函数] 请教动态库调用静态库的问题 [复制链接]

论坛徽章:
0
发表于 2014-11-17 16:50 |显示全部楼层
本帖最后由 wzabcd1234 于 2014-11-17 17:00 编辑

您好:
     写了一个测试程序如下:
     a_func.c
     int a_func(int arg)
    {
        int ret = 0;

        printf("a_func [%d]\n", arg);
    }

    so_func.c
    int so_func(int arg)
    {
        int ret = 0;

        ret = a_func(arg);

        printf("so_func [%d]\n", ret);

        return 0;
    }

    main.c

    typedef int (*mytype)(int);

    int main()
    {
        void *h = NULL;
        
        mytype sofunc;
        h = dlopen("./libsofunc.so", RTLD_LAZY);
        if (h == NULL)
        {
            printf("dlopen error\n");
            exit(1);
        }
        
        sofunc = dlsym(h, "so_func");
        if (sofunc == NULL)
        {
            printf("dlsym error\n");
            exit(1);
        }
        
        sofunc(100);
    }

    Makefile如下:

all:
        cc -g -c a_func.c
        ar -rv libafunc.a a_func.o
        cc -g -G -qmkshrobj -o libsofunc.so so_func.c
        cc -g -c main.c
        cc -o main main.o  -L. -lafunc -ldl

    想要做的事就是main调用so中的so_func,然后so_func调用a_func,但是运行main之后直接coredump了,core在so_func中调用a_func的哪一行,请教各路大神,这是什么原因?谢谢。
    PS:我的测试环境是AIX

论坛徽章:
0
发表于 2014-11-17 20:19 |显示全部楼层
http://oss.org.cn/ossdocs/apache/httpd/2.0-cn/dso.html
现代类Unix的系统都有一种叫动态共享对象(DSO)的动态连接/加载的巧妙的机制,从而可以在运行时刻,将编译成特殊格式的代码加载到一个可执行程序的地址空间。

加载的方法通常有两种:其一是,在可执行文件启动时由系统程序ld.so自动加载;其二是,在执行程序中手工地通过Unix加载器的系统接口执行系统调用dlopen()/dlsym()以实现加载。

按第一种方法,DSO通常被称为共享库(shared libraries)或者DSO库(DSO libraries),使用libfoo.so或者libfoo.so.1.2的文件名,被存储在系统目录中(通常是/usr/lib),并在编译安装时,使用连接器参数-lfoo建立了指向可执行程序的连接。通过设置连接器参数-R或者环境变量LD_LIBRARY_PATH,库中硬编码了可执行文件的路径,使Unix加载器能够定位到位于/usr/lib的libfoo.so,以解析可执行文件中尚未解析的位于DSO的符号。

通常,DSO不会引用可执行文件中的符号(因为它是通用代码的可重用库),也不会有后继的解析动作。可执行文件无须自己作任何动作以使用DSO中的符号,而完全由Unix加载器代办(事实上,调用ld.so的代码是被连入每个可执行文件的非静态运行时刻启动代码的一部分)。动态加载公共库代码的优点是明显的:只需要在系统库libc.so中存储一个库代码,从而为每个程序节省了磁盘存储空间。

按第二种方法,DSO通常被称为共享对象(shared objects)或者DSO文件(DSO files),可以使用任何文件名(但是规范的名称是foo.so),被存储在程序特定的目录中,也不会自动建立指向其所用的可执行文件的连接,而由可执行文件在运行时自己调用dlopen()来加载DSO到其地址空间,同时也不会进行为可执行文件解析DSO中符号的操作。Unix加载器会根据可执行程序的输出符号表和已经加载的DSO库自动解析DSO中尚未解析的符号(尤其是无所不在的libc.so中的符号),如此DSO就获得了可执行程序的符号信息,就好象是被静态连接的。

最后,为了利用DSO API的优点,执行程序必须用dlsym()解析DSO中的符号,以备稍后在诸如指派表等中使用。也就是说,执行程序必须自己解析其所需的符号。这种机制的优点是允许不加载可选的程序部件,直到程序需要的时候才被动态地加载(也就不需要内存开销),以扩展程序的功能。

虽然这种DSO机制看似很直接,但至少有一个难点,就是在用DSO扩展程序功能(即第二种方法)时为DSO对可执行程序中符号的解析,这是因为,“反向解析”可执行程序中的DSO符号在所有标准平台上与库的设计都是矛盾的(库不会知道什么程序会使用它)。实际应用中,可执行文件中的全局符号通常不是重输出的,因此不能为DSO所用。所以在运行时刻用DSO来扩展程序功能,就必须找到强制连接器输出所有全局符号的方法。

共享库是一种典型的解决方法,因为它符合DSO机制,而且为操作系统所提供的几乎所有类型的库所使用。另一方面,使用共享对象并不是许多程序为扩展其功能所采用的方法。

截止到1998年,只有少数软件包使用DSO机制在运行时刻实际地扩展其功能,诸如Perl 5(通过其XS机制和DynaLoader模块), Netscape Server等。从1.3版本开始,Apache也加入此列,因为Apache已经用了基于指派表(dispatch-list-based)的方法来连接外部模块到Apache的核心。所以,Apache也就当然地在运行时刻用DSO来加载其模块。

论坛徽章:
0
发表于 2014-11-18 09:09 |显示全部楼层
回复 2# magiclvzs

你好,你贴的这段是说我要自己将静态库中的函数动态加载到可执行文件中吗?

论坛徽章:
0
发表于 2014-11-19 10:04 |显示全部楼层
本帖最后由 seaquester 于 2014-11-19 11:39 编辑

回复 1# wzabcd1234


    你的Makefile写得有问题,我这边根本编译不了。
我看了一下,最大的问题是,编译libsofunc.so的时候,没有链接 libafunc.a (这是一个静态库,必须要链接进去才可以用)。
我修改了一下Makefile,在CetnOS6上测试通过,运行正常:

  1. all:
  2.         cc -g -fPIC -c a_func.c
  3.         ar -rv libafunc.a a_func.o
  4.         cc -shared -fPIC -o libsofunc.so so_func.c -L. -lafunc
  5.         cc -c main.c
  6.         cc -o main main.o -ldl

  7. clean:
  8.         rm -rf *.so *.o *.a main

复制代码
另外,你的代码真的有很多地方没注意:没有包含必须的头文件,a_func函数明明定义的是返回int类型,函数里面根本没有return语句。
自己打开-Wall 编译警告看看吧。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP