Release binaries are missing symbols

[bnoordhuis]

Taking v8::Object::CreationContext() as an example:

v0.10.24:

$ nm node-v0.10.24-linux-x64/bin/node | grep CreationContext
00000000005af500 T _ZN2v86Object15CreationContextEv
# ok

Local (clean) build:

$ nm out/Release/node | grep CreationContext
00000000005d0bf0 T _ZN2v86Object15CreationContextEv
00000000005c0eb0 T _ZN2v88internal29AllocationSiteCreationContext13EnterNewScopeEv
00000000005c0d30 T _ZN2v88internal29AllocationSiteCreationContext9ExitScopeENS0_6HandleINS0_14AllocationSiteEEENS2_INS0_8JSObjectEEE
00000000005c0d10 W _ZN2v88internal29AllocationSiteCreationContextD0Ev
00000000005c0cc0 W _ZN2v88internal29AllocationSiteCreationContextD1Ev
00000000005c0cc0 W _ZN2v88internal29AllocationSiteCreationContextD2Ev
0000000000ae3960 V _ZTVN2v88internal29AllocationSiteCreationContextE
# ok

v0.11.10:

$ nm node-v0.11.10-linux-x64/bin/node | grep CreationContext
00000000005c6a90 T _ZN2v88internal29AllocationSiteCreationContext13EnterNewScopeEv
00000000005c6c30 T _ZN2v88internal29AllocationSiteCreationContext9ExitScopeENS0_6HandleINS0_14AllocationSiteEEENS2_INS0_8JSObjectEEE
00000000005c6970 W _ZN2v88internal29AllocationSiteCreationContextD0Ev
00000000005c6960 W _ZN2v88internal29AllocationSiteCreationContextD1Ev
00000000005c6960 W _ZN2v88internal29AllocationSiteCreationContextD2Ev
0000000000a65220 V _ZTVN2v88internal29AllocationSiteCreationContextE
# bad

/cc @tjfontaine @rmg

[bnoordhuis]

FWIW, checkout out the v0.11.10 tag and running make binary DESTCPU=x64 produces a binary that has the missing symbols. I suspect it's a toolchain issue on the side of whoever built the last few release binaries (@tjfontaine?).

[tjfontaine]

all of those are built on ancient centos 5.7 to accommodate people seeking equally ancient glibc versions

[bnoordhuis]

Let me guess, really old gcc and binutils? What happens when you use a back-port of newer versions?

For comparison, the v0.11.10 release binary has ~18.5k symbols while a local build has about ~72k, almost 4x as many.

[rmg]

@tjfontaine does that mean the 0.10.24 binaries weren't built on the same machines as 0.11.10?

Could there have been a change in V8 that is confusing the older toolchain about what symbols need to be preserved while optimizing?

[tjfontaine]

@rmg no they were built on the same machine and toolchain, most of the symbol differences I see above in ben's original post are related to the normal v8 api differences between v0.10 and master, aside from the single symbol that's actually in question

I will look and see what other toolchains I have available via back ports

[jeromew]

I don't know if this is of any help, but apparently chromium stopped supporting RHEL6 after chromium 28 - https://code.google.com/p/chromium/issues/detail?id=227320 around april 2013.

[tjfontaine]

We're using gcc/g++ 4.4 from their backports, and have binutils220 as well, but that doesn't include a newer ld, so we're still using the ld from binutils 2.17. Seems that could be the actual culprit here as we're doing whole-archive now there's no reason for it to be dropping any symbols.

[tjfontaine]

@bnoordhuis @rmg I've installed gcc 4.7 and binutils 2.35 and my nm seems right, please confirm this solves it for you guys? http://nodejs.org/dist/nightlies/master/v0.11.11-nightly-20140108/node-v0.11.11-nightly-20140109-linux-x64.tar.gz

[rmg]

@tjfontaine sure thing. I'll report back when I've got results.

[rmg]

In the immortal words of every developer ever... "works for me!" 👍

That seems to have done the trick.

[bnoordhuis]

Yep, works. Thanks, TJ.