Link to another node module

[Queuecumber]

I have a few node modules in my project, one of which, module B uses code defined in module A. I have listed module A as a dependency of module B using the "dependencies" directive of the binding.gyp, but when I call function functions in module B, I get undefined symbol errors for code that is defined in module A. This tells me that node-gyp is not linking module B against module A to resolve the code. Is there a way to resolve this behavior?

[bnoordhuis]

When you say "module", do you mean separate .node files? Perhaps you can post your binding.gyp(s)?

[Queuecumber]

Yes I mean separate .node files. Here is an excerpt

{
            "target_name": "classificationTesting",

            "sources": [...
            ],

            "libraries": [
                "<!@(pkg-config --libs opencv)",
                "-lboost_system",
                "-lboost_filesystem",
                "-lboost_regex",
                "-lvl",
                "<!@(pkg-config --libs tinyxml)"
            ],

            "include_dirs": [
                "api",
                "<!(node -e \"require('nan')\")"
            ],

            "cflags": [ "-std=c++11", "-w", "<!@(pkg-config --cflags opencv)"],
            "cflags!": ["-fno-exceptions"],
            "cflags_cc!": ["-fno-rtti", "-fno-exceptions"],
        },
...
        {
            "target_name": "pairwiseTraining",

            "sources": [...
            ],

            "dependencies": [
                    "classificationTesting
            ],

            "libraries": [
                "<!@(pkg-config --libs opencv)",
                "-lboost_system",
                "-lboost_filesystem",
                "-lboost_regex",
                "<!@(pkg-config --libs tinyxml)"
            ],

            "include_dirs": [
                "api",
                "<!(node -e \"require('nan')\")",
                "pipelines/classification",
                "pipelines/imagePrep"
            ],

            "cflags": [ "-std=c++11", "-w", "<!@(pkg-config --cflags opencv)", "-fpermissive"],
            "cflags!": ["-fno-exceptions"],
            "cflags_cc!": ["-fno-rtti", "-fno-exceptions"],
        }

[bnoordhuis]

I don't think you can make that work without either:

1. Linking B directly to A so that ldd or otool -L prints B as a dependency of A, or
2. Patching node.js / libuv to open shared objects with dlopen(RTLD_GLOBAL).

I'd probably split off the shared code into a static library ('type': 'static_library' in your binding.gyp) and link that into both shared objects.

[TooTallNate]

I do actually do this with node-ogg and node-vorbis (libvorbis needs to link to libogg). The implementation has always been pretty hacky (involving changing node-ogg's "type" to shared_library, re-exporting all of libogg's symbols in the generated .node file, and more hacks), but in the end, the vorbis.node file ends up linking to the ogg.node file to access the libogg symbols:

$ otool -L build/Release/vorbis.node 
build/Release/vorbis.node:
        @rpath/ogg.node (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 915.0.0)

[Queuecumber]

Probably I will factor the common code into a static library rather than hack around the nodejs limitations