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

[yhwang]

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

[yhwang]

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.

[richardlau]

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.

[yhwang]

@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.

[yhwang]

For parallel/test-process-external-stdio-close and parallel/test-process-external-stdio-close-spawn, the close callback gets SIGPIPE. So it would be pipe related issue, i.e. not able to write/receive data from the pipe. I will dig into that. If someone knows the possible cause, please chime in. Thanks.