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]
执行结果
结果正所期望,这说明我们编码的目标,最终的运行过程还是按一些可识别易理解的符号来展开的,而不是一些固态寻址的过程。站在应用的高度来观察问题,总比陷在底层拘泥于代码好很多,哈哈。试想哪个汇编程序员的世界如果不拓展一下自己的见识,又怎知高级语言以及其他技术选择的优雅与便捷呢。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。