| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
@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 |
Sorry, something went wrong.
|
/CC @nodejs/build @nodejs/build-files Posted to reevaluate our approach to static linking to the compiler libraries:
But:
|
Sorry, something went wrong.
|
Last discussion I found that's around this - #4152 |
Sorry, something went wrong.
|
can you show us a binary file size difference with this on for master? |
Sorry, something went wrong.
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)) [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/nodepost (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 |
Sorry, something went wrong.
|
Another datapoint, Ubuntu Xenial (only 1MB or ~2.5%): [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/nodepost (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 |
Sorry, something went wrong.
There was a problem hiding this comment.
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>.
Sorry, something went wrong.
There was a problem hiding this comment.
Should be default=True,, no quotes.
Sorry, something went wrong.
|
@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). |
Sorry, something went wrong.
* remove the dependancy of the binary on installed compilers
|
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. |
Sorry, something went wrong.
|
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. $ 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
36897There 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":
|
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes: nodejs/build#1724
Refs: nodejs/build#1543
Checklist