Ldflags "-lcrypto", "-lssl" and "-lz" are needed on
IBMi PASE to build the test suite

Those tests are testing addons can build against the openssl and zlib bindings statically linked into the Node.js binary so linking to external libraries negates the purpose of those tests. Or does Node.js on IBMi PASE always build against the system openssl/zlib?

Ldflags "-lcrypto", "-lssl" and "-lz" are needed on
IBMi PASE to build the test suite

Those tests are testing addons can build against the openssl and zlib bindings statically linked into the Node.js binary so linking to external libraries negates the purpose of those tests. Or does Node.js on IBMi PASE always build against the system openssl/zlib?

Yes, Node.js on IBMi PASE always links to the system libraries (no static linking). Or maybe I should skip these cases?

Anyone know what the Linux packagers that link against shared libraries do?

1. If only skip them on IBMi PASE, I can just simply edit addon.status like ARM.
2. If it affect all shared openssl/zlib builds, maybe we should consider to add the conditions of node_shared_openssl & node_shared_zlib like this?

Hello @addaleax ,
I tried to skip the tests using [$system==ibmi]. But it seems has no effect. So I changed the commit using the 2nd solution. Is it acceptable?
Or would you tell me how to skip these two tests on IBMi?

Anyone know what the Linux packagers that link against shared libraries do?

I tried to compile node.js with shared openssl&zlib on CentOS and the addon tests showed no error. I guess that even in this 'shared' configuration, the Linux node.js build can also bind to the static libraries as well. But it does not work on IBMi PASE.

@dmabupt how many/what tests don't pass?

@dmabupt how many/what tests don't pass?

Hello @mhdawson , There are 18 failed tests --
[21:48|% 100|+ 2907|- 18]: Done
Below test results are from the make test-only test of node-v14.0.0-nightly2020022720a51b9dff.
Some of the 18 failed tests are waiting for the fixes from libuv

1. parallel/test-dummy-stdio Error: ERR_TTY_INIT_FAILED
2. parallel/test-net-keepalive Error: read ECONNRESET
3. parallel/test-net-persistent-keepalive Error: read ECONNRESET
4. parallel/test-net-socket-connect-without-cb Error: read ECONNRESET
5. parallel/test-net-socket-close-after-end Error: read ECONNRESET
6. parallel/test-net-socket-connecting Error: read ECONNRESET
7. parallel/test-net-socket-local-address Error: read ECONNRESET
8. parallel/test-net-socket-ready-without-cb Error: read ECONNRESET
9. parallel/test-net-write-after-end-nt Error: read ECONNRESET
10. parallel/test-os Error: os.freemem() <= 0
11. parallel/test-tls-env-extra-ca Error: read ECONNRESET
12. parallel/test-tls-peer-certificate-multi-keys Error: read ECONNRESET
13. parallel/test-tls-peer-certificate-encoding Error: read ECONNRESET
14. parallel/test-ttywrap-invalid-fd Error: ERR_TTY_INIT_FAILED
15. wasi/test-wasi AssertionError [ERR_ASSERTION]
16. addons/openssl-binding/test
17. addons/zlib-binding/test
18. pseudo-tty/test-tty-isatty 55555 reported to be a tty, but it is not

So these are the only 2 that are related to the addons:

addons/openssl-binding/test
addons/zlib-binding/test

Sounds like you did tests on linux, though and excluding them in the way you suggest does not make sense since the tests still run ok there.

We should see if we can get the excludes working properly.

Looking at the test code seems that the platform should be detected as OS400 by the test harness and maps to 'ibmi' so using [$system==ibmi] should work.

In what file did you add that along with the tests ? I think you would have to add to .../test/addons/addon.status

and something like this

[$system==ibmi]
addons/openssl-binding/test: SKIP
addons/zlib-binding/test: SKIP

Looking at the test code seems that the platform should be detected as OS400 by the test harness and maps to 'ibmi' so using [$system==ibmi] should work.

In what file did you add that along with the tests ? I think you would have to add to .../test/addons/addon.status

and something like this

[$system==ibmi]
addons/openssl-binding/test: SKIP
addons/zlib-binding/test: SKIP

Yes, but I missed the addons path and wrote openssl-binding/test: SKIP. That may be the problem.

@dmabupt ok let us know if fixing up the paths works.

@dmabupt ok let us know if fixing up the paths works.

@mhdawson , Seems it still can not skip the cases --

Error: Command failed: /home/XUMENG/rpmbuild/BUILD/node-v14.0.0-nightly202003026bcea0a383/out/Release/node /home/XUMENG/rpmbuild/BUILD/node-v14.0.0-nightly202003026bcea0a383/deps/npm/node_modules/node-gyp/bin/node-gyp.js rebuild --directory=/home/XUMENG/rpmbuild/BUILD/node-v14.0.0-nightly202003026bcea0a383/test/addons/openssl-binding
ld: 0711-224 WARNING: Duplicate symbol: std::_Sp_counted_ptr<decltype(nullptr), (__gnu_cxx::_Lock_policy)2>::_M_dispose()
ld: 0711-224 WARNING: Duplicate symbol: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_destroy()
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
ld: 0711-317 ERROR: Undefined symbol: .TLSv1_2_server_method
ld: 0711-317 ERROR: Undefined symbol: .RAND_poll
ld: 0711-317 ERROR: Undefined symbol: .RAND_bytes
collect2: error: ld returned 8 exit status
gmake[2]: *** [binding.target.mk:145: Release/obj.target/binding.node] Error 1

The patch is --

--- a/test/addons/addon.status
+++ b/test/addons/addon.status
@@ -9,3 +9,7 @@ prefix addons
 [$arch==arm]
 # https://github.com/nodejs/node/issues/30786
 openssl-binding/test: PASS,FLAKY
+
+[$system==ibmi]
+addons/openssl-binding/test: SKIP
+addons/zlib-binding/test: SKIP

Is it failing in the build step as opposed to the test step?

Is it failing in the build step as opposed to the test step?

@mhdawson , It is failing in the make test-only step. More precisely, in the make build-addons step.

To skip the build step, we have to edit this file (not that gracefully) --

--- a/tools/build-addons.js
+++ b/tools/build-addons.js
@@ -28,7 +28,8 @@ async function runner(directoryQueue) {
       return next();
     throw err;
   }
-
+  if(dir.indexOf('openssl-binding') >= 0 || dir.indexOf('zlib-binding') >= 0)
+    return next();
   console.log(`Building addon in ${dir}`);
   const { stdout, stderr } =
     await execFile(process.execPath, [nodeGyp, 'rebuild', `--directory=${dir}`],

@dmabupt can you add guards based on IBMi based on the platform in the test files, for example in node/test/addons/zlib-binding which avoids the compile failures, that along with the excludes might work and be a better answer.

@dmabupt can you add guards based on IBMi based on the platform in the test files, for example in node/test/addons/zlib-binding which avoids the compile failures, that along with the excludes might work and be a better answer.

@mhdawson Do you mean updating node/test/addons/zlib-binding/binding.gyp to skip IBMi systems?

Was not thinking of that, more changing the code in the cc file so that it still compiles (but obviously not work), if we can make the gyp file not compile it for IBMi that might be even better.

Was not thinking of that, more changing the code in the cc file so that it still compiles (but obviously not work), if we can make the gyp file not compile it for IBMi that might be even better.

Updating the c code to make it build a dummy executable file on IBMi, then both the build step and test step can be passed (skipped) ?

Was not thinking of that, more changing the code in the cc file so that it still compiles (but obviously not work), if we can make the gyp file not compile it for IBMi that might be even better.

Updating the c code to make it build a dummy executable file on IBMi, then both the build step and test step can be passed (skipped) ?

Seems it is not that easy. The zlib js test code deflates the data compressed by the compiled C code, and then compares it with the origin buffer -- https://github.com/nodejs/node/blob/master/test/addons/zlib-binding/test.js#L12

That means we have to change the js code as well if we skip the logic in the C code.

But if the test is skipped then it should not matter what is in the js code right?

But if the test is skipped then it should not matter what is in the js code right?

@mhdawson

• The openssl binding test can do this because its C code just simply return true/false.
• But the zlib binding test's C code returns a zlib compressed object which should be correctly extracted by its js code.
• I mean, the zlib binding test contains two parts. The C code is just the compression stage. The js code is part of the test as well -- the decompression stage.

@dmabupt I don't understand your point. If the test is skipped in the status file the js code will not run, correct?

@dmabupt I don't understand your point. If the test is skipped in the status file the js code will not run, correct?

@mhdawson
The js code will not run, but the c code will still be compiled with error. The status file does not control the compiling step. And because of the compiling failure, the test process ends, any following js code even has no chance to run.

Now I think if we want to minimize the code change, my initial workaround (adding -lssl, -lz to the gyp file to make the two tests pass on IBMi PASE) is still a choice.

@dmabupt your original change seemed to affect all platforms. It might be ok if it only affect IBM i

@dmabupt your original change seemed to affect all platforms. It might be ok if it only affect IBM i

My following force push actions have overwritten the first commit. In that commit, the ldflags are only added on platform ibmi.

Hello @mhdawson , I have reverted the commits to the initial one -> 4df86c9 . This change only affect the IBMi PASE platform and it makes the two failed tests skipped (both compile & test steps).
Hello @addaleax , Would you review the commit 4df86c9 please? I think it minimizes the impact if we just want to skip the two tests.

CI: https://ci.nodejs.org/job/node-test-pull-request/30217/

CI: https://ci.nodejs.org/job/node-test-pull-request/30245/

Landed in b416993

@dmabupt This is failing to build on Windows machines that do not have uname available, fyi.

@dmabupt This is failing to build on Windows machines that do not have uname available, fyi.

Ah...yes, I should detect uname only in the aix condition. I opened another PR for the fix on Windows.