Linux hooves a shared Object

Scenario Overview

The recent Contact node program and the call to implement the node extension to the object's local SDK are designed to quickly implement restful APIs and use it to browsers using node and its third-party libraries. Of course, this intermediate research work takes a lot of time.

In the implementation of the target extension, due to the presence of some event states of the SDK calls and processing by the upper layer, in order to facilitate the visibility of the model in order to be easy to understand, it still feels the need to provide this feature to the script layer control as well. This requires the use of the attributes of the asynchronous notification event to node.

For asynchronous parallel design, the node framework is supported by LIBUV, and the Extender wants to interact with the framework engine thread, so that the extension still needs to rely on LIBUV.

The problem now is that the node launcher I'm compiling now, on a target, integrates the V8 engine and libuv/c-ares/http_parser these third-party libraries. There is also no way to find ways to peel these libraries, of course, it is also thought that the target environment is embedded in the board to run, if these dependencies are independent shared library files, the overall product may be released larger.

Now the problem can be simply described, I need to compile the shared library relies on LIBUV, and this feature has been integrated in the launch target. I need to determine if this dependency is feasible and ensure that the extension can use the functionality in the launcher.

Breaking down the problem to the most meticulous is the need to verify this symbol dependency, and will not encounter the runtime symbol can not solve the problem.

Test

//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>voidSo_call ();voidtest (); #ifndef so_compilevoidTest () {printf ("%s-from main program\n", __function__);}intMainintargcChar Const*argv[]) {    /*Code*/So_call (); return 0;}#elsevoidSo_call () {printf ("%s-from shared library\n", __function__); Test ();}#endif//So_compile

A.out

Main-->[email protected]

Test

Liba.so

So_call-->[email protected]

Execution results

The results are expected, and this shows that the goal of our coding, and ultimately the process of running it, is based on some recognizable symbols, rather than some solid-state addressing. Standing in the application of the height to observe the problem, is always more than stuck in the bottom of the code a lot better, haha. Imagine the world of assembler programmers who don't broaden their horizons and know the elegance and convenience of high-level languages and other technology choices.

Linux hooves a shared Object