build: make partly_static opt-out

[refack]

• remove the dependency of the binary on installed compilers

Fixes: nodejs/build#1724
Refs: nodejs/build#1543

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

@refack build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2954/pipeline

[refack]

/CC @nodejs/build @nodejs/build-files

Posted to reevaluate our approach to static linking to the compiler libraries:

• CLang already does something similar (with libc++)
• This should alleviate our woes regarding binary cross-compatibility with systems that do not include the exact version of our compiler.

But:

• It does make the binary bigger
• Native module interop needs to be validated.

[refack]

Last discussion I found that's around this - #4152
Some refs: https://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas

[richardlau]

Also nodejs/help#951

[rvagg]

can you show us a binary file size difference with this on for master?

[refack]

can you show us a binary file size difference with this on for master?

I run this on linuxONE (where BTW our vanilla binary throws /lib64/libstdc++.so.6: version 'GLIBCXX_3.4.20' not found (required by ./node))
pre (45'841'792):

[iojs@test-linuxonecc-rhel72-s390x-1 rhel72-s390x]$ ldd out/Release/node
out/Release/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by out/Release/node)
        libdl.so.2 => /lib64/libdl.so.2 (0x000003ffb9d80000)
        librt.so.1 => /lib64/librt.so.1 (0x000003ffb9d00000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x000003ffb9b80000)
        libm.so.6 => /lib64/libm.so.6 (0x000003ffb9a80000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000003ffb9a00000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000003ffb9980000)
        libc.so.6 => /lib64/libc.so.6 (0x000003ffb9780000)
        /lib/ld64.so.1 (0x000003ffb9e80000)
[iojs@test-linuxonecc-rhel72-s390x-1 rhel72-s390x]$ ls -la out/Release/node
-rwxr-xr-x 1 iojs iojs 45841792 Mar 18 08:33 out/Release/node

post (52'055'208)

[iojs@test-linuxonecc-rhel72-s390x-1 rhel72-s390x]$ ldd out/Release/node
        libdl.so.2 => /lib64/libdl.so.2 (0x000003ff85a00000)
        librt.so.1 => /lib64/librt.so.1 (0x000003ff85980000)
        libm.so.6 => /lib64/libm.so.6 (0x000003ff85880000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000003ff85800000)
        libc.so.6 => /lib64/libc.so.6 (0x000003ff85600000)
        /lib/ld64.so.1 (0x000003ff85b00000)
[iojs@test-linuxonecc-rhel72-s390x-1 rhel72-s390x]$ ls -la out/Release/node
-rwxrwxr-x 1 iojs iojs 52055208 Mar 18 09:18 out/Release/node

[refack]

Another datapoint, Ubuntu Xenial (only 1MB or ~2.5%):
pre (42'883'024)

[iojs@ubuntu1604]$ ldd out/Release/node
        linux-vdso.so.1 =>  (0x00007ffcd99b7000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff3eb8d5000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff3eb6cd000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff3eb34b000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff3eb042000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff3eae2c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff3eac0f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff3ea845000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff3ebad9000)
[iojs@ubuntu1604]$ ls -la out/Release/node
-rwxrwxr-x 1 iojs iojs 42883024 Mar 18 13:41 out/Release/node

post (43'889'160)

[iojs@ubuntu1604-x64]$ ldd out/Release/node
        linux-vdso.so.1 =>  (0x00007ffe503fd000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7ebade4000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7ebabdc000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7eba8d3000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7eba6b6000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7eba2ec000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7ebafe8000)
[iojs@ubuntu1604]$ ls -la out/Release/node
-rwxrwxr-x 1 iojs iojs 43889160 Mar 18 13:48 out/Release/node

[bnoordhuis]

The goal is to enable partially static builds by default? -static-libstdc++ is unlikely to be what we want for release builds. It's also not a good default for distro packagers. It might wreak havoc with add-ons that are linked to a different stdlib.

--not-partly-static is kind of an awkward name, other opt-out options start with --no-<name>.

[bnoordhuis]

Should be default=True,, no quotes.

[rvagg]

@bnoordhuis "-static-libstdc++ is unlikely to be what we want for release builds" - we're trying to find a way upward on GCC version for Node 12 while supporting currently supported distros as much as possible (Node 12 supported platforms planning - #26714 - your input would be great). On x64 it's easy because devtoolset gives us their backward compat magic, but on anything else (ARM, IBM, maybe SmartOS) we're stuck with lowest-common-denominator and knocking out some OS versions (Ubuntu 16.04 on ARM would be out if we go to GCC-6, for example).

[mhdawson]

I am worried about the impact to addon binaries as well, particularly if it means that it breaks the N-API stability promise.

I think we need to very carefully understand all of the implications of this kind of change. Ideally, we'd make it just after cutting a release so we'd have more time in master to see what/if issues arise.

[refack]

Fixes: #26877

[refack]

Some info about how RH's dev-toolset solves this issue. They create a delta library libstdc++_nonshared.a which is statically linked to binaries if they require any of it's symbols.
This library has ~30% of the symbols that libstdc++.so.6.26 holds:

$ objdump -x /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8/libstdc++.a | wc -l
99322
$ objdump -x /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8/libstdc++_nonshared.a | wc -l
36897

There is no consensus on the "internet" about the optimal solution to this problem. From my survey it seems like these are the common solutions, ranked in order of empirical "safety":

1. requiring users to update libstdc++
2. using libstdc++_nonshared.a
3. static linking, as in this PR
4. packing libstdc++.so.6.21 with our binary and linking with -Wl,-rpath,'$ORIGIN'

[jasnell]

There's been no activity on this in over a year. It's not clear if it should move forward or not. Closing it as stalled but we can reopen if necessary. @nodejs/build