When I tried to link the plugin template with the inferno code I found some problems. I need to call inferno functions from the plugin code, inferno code is linked as a shared librery with the plugin code, so it's possible to call inferno functions and to put includes of inferno headers without telling the plugin where are the inferno headers.
It's important to use 'nm' in order to know the symbol definition table, if a call to a inferno function from the plugin code is defined there is no problem, that is, the links are right.
The real trouble I have is the redefinition of malloc(s) functions, the inferno code redefines malloc,free, and many other functions, when emu is compiled as a static executable there is no problem because malloc/free are local symbols and when a call to malloc/free is found it's mapped to the malloc/free redefinition in the inferno code. But when inferno is compiled as a shared library and it's dynamically loaded from firefox, the malloc/free calls from the inferno code are mapped to the libc malloc/free instead the inferno ones. This happens because of firefox uses the standard malloc/free functions from libc, and it's statically linked, so the malloc of libc is found before the malloc redefinition within inferno code.
Shared libraries must import any symbols they use but do not define. But it's possible to import symbols that are defined in the shared library. Even though malloc is in the library, nothing else there refers to it directly; all references are through an imported symbol pointer. If the application does not redefine malloc, both application and library calls are routed to the library version. All calls are mapped to the alternate, if present.
