Linux嘚瑟一时的Shared Object

场景概述

近来接触node程序以及负责实现node扩展来对象本地SDK的调用,旨在借node及其第三方库来快速实现RESTful API以及给浏览器端使用。当然这中间研究工作耗了不少时间。

在实现目标扩展中,因SDK调用存在一些事件状态需要关注且由上层处理,为了便于模型的可视性为了易于理解,因此还是觉得需要把该特性提供到脚本层控制为好。这就需要使用到node的异步通知事件的特性。

对于异步并行设计,node框架是借助了libuv的支持,而扩展程序欲与框架引擎线程交互,于是说扩展还是需要依赖libuv。

问题出现在,我现在编译出来的node启动程序,就一个目标,集成了v8引擎,libuv/c-ares/http_parser这些第三方库于一身。目前也未寻找到方法剥离这些库,当然也想到发布的目标环境是嵌入到板子里运行,如果这些依赖关系是独立的共享库文件,可能发布的总体积会大些。

现在的问题就可以简单的描述说,我需要编译的共享库依赖libuv,而这块功能已经集成在启动目标中。我需要确定这种依赖是否可行,保证扩展可以使用启动程序中的功能。

把问题分解到最细致,就是需要验证这种符号依赖,会不会遇到运行时符号无法解决的问题。

试验

// test symbol depend on the main
// a.out <--> liba.so // need each symbol
// generate lib.so
// gcc -shared -o liba.so test.c -D SO_COMPILE
// generate a.out
// gcc test.c -L ./ -la -Wl,-rpath,./
// run ./a.out

#include <stdio.h>

void so_call();
void test();

#ifndef SO_COMPILE
void test()
{
    printf("%s -from main program\n", __FUNCTION__);
}
int main(int argc, char const *argv[])
{
    /* code */
    so_call();
    return 0;
}
#else
void so_call()
{
    printf("%s -from shared library\n", __FUNCTION__);
    test();
}
#endif//SO_COMPILE

a.out

main -->[email protected]

test

liba.so

so_call -->[email protected]

执行结果

技术分享

 

结果正所期望,这说明我们编码的目标,最终的运行过程还是按一些可识别易理解的符号来展开的,而不是一些固态寻址的过程。站在应用的高度来观察问题,总比陷在底层拘泥于代码好很多,哈哈。试想哪个汇编程序员的世界如果不拓展一下自己的见识,又怎知高级语言以及其他技术选择的优雅与便捷呢。

 

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。