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 ;
}
#else
void so_call()
{
    printf("%s -from shared library\n", __FUNCTION__);
    test();
}
#endif//SO_COMPILE

a.out

main -->so_call@liba.so

test

liba.so

so_call -->test@a.out

执行结果

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