canvas module does not work with ncc v0.3.0

[TooTallNate]

It correctly copies the canvas.node file:

$ ls dist/
canvas.node  index.js  index.js.map

However, canvas also bundles the shared libs that it relies on:

$ otool -L dist/canvas.node
dist/canvas.node:
        @loader_path/libpixman-1.0.dylib (compatibility version 35.0.0, current version 35.0.0)
        @loader_path/libcairo.2.dylib (compatibility version 11603.0.0, current version 11603.0.0)
        @loader_path/libpng16.16.dylib (compatibility version 52.0.0, current version 52.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
        @loader_path/libpangocairo-1.0.0.dylib (compatibility version 4201.0.0, current version 4201.4.0)
        @loader_path/libpango-1.0.0.dylib (compatibility version 4201.0.0, current version 4201.4.0)
        @loader_path/libgobject-2.0.0.dylib (compatibility version 5801.0.0, current version 5801.1.0)
        @loader_path/libglib-2.0.0.dylib (compatibility version 5801.0.0, current version 5801.1.0)
        @loader_path/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0)

$ ls node_modules/canvas/build/Release/
canvas.node*          libffi.6.dylib         libfribidi.0.dylib         libgio-2.0.0.dylib      libgobject-2.0.0.dylib    libharfbuzz.0.dylib  libpango-1.0.0.dylib       libpcre.1.dylib      librsvg-2.2.dylib
libcairo.2.dylib      libfontconfig.1.dylib  libgdk_pixbuf-2.0.0.dylib  libglib-2.0.0.dylib     libgraphite2.3.2.1.dylib  libintl.8.dylib      libpangocairo-1.0.0.dylib  libpixman-1.0.dylib  obj.target/
libcroco-0.6.3.dylib  libfreetype.6.dylib    libgif.7.dylib             libgmodule-2.0.0.dylib  libgthread-2.0.0.dylib    libjpeg.9.dylib      libpangoft2-1.0.0.dylib    libpng16.16.dylib

Proposal

When the native module case is hit, ncc should also look for shared libraries appropriate for the operating system (.dylib for MacOS, .so for Linux, .dll for Windows, etc.) relative to the .node file and copy them into the output bundle as well.

[guybedford]

@TooTallNate how hard would it be to replicate the binary analysis from otool -L here? If we know the right binary headers to check this should be straightforward right?

It would just be nicer to avoid random globbing where possible...

[guybedford]

I guess it wouldn't work cross platform, which would be the main concern as that's a lot of work to analyze all different binary types...

[guybedford]

I guess there would also be the issue that dynamic libraries can reference dynamic libraries here... so it gets a little bit too much...

Do you think the assumption is ok that we only support ./**/*.(dll|dylib|so)? How often do you think backtracking patterns might be used to reach shared binaries? I guess we will find out!

[TooTallNate]

Honestly I don't think many native modules bundle shared libs like this. My personal preference is to statically compile the dep and build it into the .node module.

Other modules usually just depend on the system shared lib being installed from the package manager, but I don't really think we need to support that use-case (at least, it would require runtime trickery with the LD_LIBRARY_PATH env var which isn't ideal).