Some test cases fail when the node executable is built by --shared

When use --shared option in configure, it would build the node in shared lib for people who embed node in their applications. It also uses the node_main.cc to build the node executable with the shared lib. When using this executable to run our existing test suites, the following test cases fail:

Ubuntu 16.04:

parallel/test-child-process-fork-exec-path
parallel/test-module-loading-globalpaths
parallel/test-postmortem-metadata
parallel/test-process-external-stdio-close
parallel/test-process-external-stdio-close-spawn
parallel/test-stdout-close-catch
abort/test-abort-backtrace

Maybe some of them are not suitable for shared lib build, maybe some are bugs. Fixing them would help us to have a CI job to build node in shared lib and verify it. This would also help embedding users to make sure the shared lib work. And we can start from Linux platform.

Platform: Linux
Subsystem: test

I am going to start to check the root causes for these test cases. I will update my finding here and fix if needed. Of course, comment/suggestion are welcome.

parallel/test-module-loading-globalpaths copies the node executable into a temporary directory and runs the copy as some of the global paths are relative to where the binary is. I would guess that with the shared lib the copied node executable is unable to find/load the shared lib.

@richardlau

@richardlau

I would guess that with the shared lib the copied node executable is unable to find/load the shared lib.

You're right. And both parallel/test-child-process-fork-exec-path and parallel/test-module-loading-globalpaths share the same issue. In Linux platform, gyp uses rpath=$ORIGIN/lib.target to build the executable. One way to fix it is adding LD_LIBRARY_PATH (DYLD_LIBRARY_PATH for macOS, LIBPATH for AIX) into process.env. Both of them passed when I tried this locally.