src: fix dynamically linked zlib version

[richardlau]

Report the version of the dynamically linked zlib if built with configure --shared-zlib instead of the hardcoded version that corresponds to the bundled version of zlib in deps.

Refs: #50910 (comment)
Refs: #50158

---

This should unblock #50910 by fixing the regression caused by #50158.

[nodejs-github-bot]

Review requested:

• @nodejs/gyp

[nodejs-github-bot]

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

[richardlau]

So this fixes the immediate bug -- prior to this PR process.versions.zlib would incorrectly report 1.2.13.1-motley-5daffc7 which is the value in src/zlib_version.h that was set the last time deps/zlib was updated.

One interesting observation is that, after building with --shared-zlib if I run with a different (but ABI compatible) version of zlib, process.versions still reports the version linked against but process.report.getReport().header.componentVersions shows the expected version.
e.g.

iojs@bd40e8f13f4d:/node$ LD_LIBRARY_PATH=/opt/zlib_1.2.12/lib/ ./node -p process.config.target_defaults{ cflags: [], default_configuration: 'Release', defines: [ 'NODE_OPENSSL_CONF_NAME=nodejs_conf', 'NODE_OPENSSL_HAS_QUIC', 'ICU_NO_USER_DATA_OVERRIDE' ], include_dirs: [ '/opt/zlib_1.2.12/include/' ], libraries: [ '-L/opt/zlib_1.2.12/lib/', '-lz' ]}iojs@bd40e8f13f4d:/node$ LD_LIBRARY_PATH=/opt/zlib_1.2.12/lib/ ./node -p process.versions.zlib1.2.12iojs@bd40e8f13f4d:/node$ LD_LIBRARY_PATH=/opt/zlib_1.2.12/lib/ ./node -p "process.report.getReport().header.componentVersions.zlib"1.2.12iojs@bd40e8f13f4d:/node$ LD_LIBRARY_PATH=/opt/zlib_1.2.12/lib/ ./node -p "process.report.getReport().sharedObjects"[ 'linux-vdso.so.1', '/opt/zlib_1.2.12/lib/libz.so.1', '/lib/x86_64-linux-gnu/libdl.so.2', '/lib/x86_64-linux-gnu/libstdc++.so.6', '/lib/x86_64-linux-gnu/libm.so.6', '/lib/x86_64-linux-gnu/libgcc_s.so.1', '/lib/x86_64-linux-gnu/libpthread.so.0', '/lib/x86_64-linux-gnu/libc.so.6', '/lib64/ld-linux-x86-64.so.2']iojs@bd40e8f13f4d:/node$

which so far is consistent, but when changing LD_LIBRARY_PATH to pick up a different version of zlib (1.2.11):

iojs@bd40e8f13f4d:/node$ LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ ./node -p process.versions.zlib1.2.12iojs@bd40e8f13f4d:/node$ LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ ./node -p "process.report.getReport().header.componentVersions.zlib"1.2.11iojs@bd40e8f13f4d:/node$ LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ ./node -p "process.report.getReport().sharedObjects"[ 'linux-vdso.so.1', '/lib/x86_64-linux-gnu/libz.so.1', '/lib/x86_64-linux-gnu/libdl.so.2', '/lib/x86_64-linux-gnu/libstdc++.so.6', '/lib/x86_64-linux-gnu/libm.so.6', '/lib/x86_64-linux-gnu/libgcc_s.so.1', '/lib/x86_64-linux-gnu/libpthread.so.0', '/lib/x86_64-linux-gnu/libc.so.6', '/lib64/ld-linux-x86-64.so.2']iojs@bd40e8f13f4d:/node$

i.e. process.report seems to be correct but process.versions is not. Are the versions in process.versions coming from the snapshot? cc @joyeecheung

[kapouer]

@richardlau serendipitously, I have a similar problem, as a distributor, when embedding builtins from system source at build time (the ones officially supported + the ones I added manually, acorn &al).
For example at build time I do this ugly stuff.

[joyeecheung]

Yes I think process.versions is captured in the snapshot at build time. If this needs to be dynamic (or any other) I think we can just reset the versions at pre-execution (something like if the process.config indicates that some library is dynamically linked, reset the version retrieved from C++ land)

[mhdawson]

LGTM

[nodejs-github-bot]

Landed in 7b3eb31