node-addon-api fails to build against node 4.x

[gabrielschulhof]

$ nvm use 4
$ npm test

Observe build failure.

[gabrielschulhof]

I tweaked the node-test-node-addon-api job a bit:

https://ci.nodejs.org/job/node-test-node-addon-api/1/ (nightly - good)
vs.
https://ci.nodejs.org/job/node-test-node-addon-api/2/ (v4 - bad)

[gabrielschulhof]

v6 is also bad: https://ci.nodejs.org/job/node-test-node-addon-api/3/

[mhdawson]

@gabrielschulhof can I assume you are investigating ? It is possible that its related to the async changes that were landed in master/head but I doubt have been backported to 4/6

[gabrielschulhof]

Is this #144?

[gabrielschulhof]

@mhdawson almost certainly, since it's precisely async that is tripping things up.

[gabrielschulhof]

Actually, node-addon-api fails to build against nov 8.4.0 too. So AFAICT it's basically broken against any version of node other than the latest.

[gabrielschulhof]

I'm starting to go through the errors, and I've noticed that we've introduced a call to v8::FunctionCallbackInfo's NewTarget() method. This method is not available in previous versions of V8, so can we fall back onto This()? Can NewTarget() be something other than This() when IsConstructCall() is true? @nodejs/addon-api

[bnoordhuis]

Can NewTarget() be something other than This() when IsConstructCall() is true?

Yes, see nodejs/node#15681. You could back-port nodejs/node#11652 to v4.x.

[gabrielschulhof]

Hmmm ... on node 8.0.0 it's building our copy of node_api.cc and it's creating node-api.a, but then the linker resolves calls to node's own version, meaning the ABI is mismatched, running into segfaults as a result.

[gabrielschulhof]

The problem can be solved with __attribute__((visibility("protected"))) but then you get the error "/usr/bin/ld: Release/obj.target/binding/error.o: relocation R_X86_64_PC32 against protected symbol `napi_create_error' can not be used when making a shared object"

[bnoordhuis]

on node 8.0.0 it's building our copy of node_api.cc and it's creating node-api.a, but then the linker resolves calls to node's own version

Static linker or dynamic linker? What do nm -C and ldd print for build/Release/*.node?

My first hunch is that it's a link order issue. What does env V=1 node-gyp rebuild print?

[gabrielschulhof]

@bnoordhuis
nm -C
ldd:

	linux-vdso.so.1 (0x00007ffd43787000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2078d42000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f2078a2c000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2078815000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f20785f6000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f2078225000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f207932b000)

V=1 npm test

I think it's a library load time issue. The symbols are available both locally (via node-api.a) and from Node.js, and the dynamic linker is resolving the needed symbols using Node's symbols rather than those from node-api.a, which is statically linked into binding.node.

Defining NAPI_EXTERN as __attribute__((visibility("hidden"))) causes the symbols in node-api.a to take precedence.

[gabrielschulhof]

Wow! Another weird consequence. The Node.js async execute callback gets called, even though the async work item is created inside node-api.a.

[gabrielschulhof]

That is, the version of uvimpl::Work::ExecuteCallback available inside node gets called, not the one available inside node-api.a.

[gabrielschulhof]

I have to qualify uvimpl::Work::ExecuteCallback and uvimpl::Work::CompleteCallback with NAPI_EXTERN in order for them to get resolved correctly.

[bnoordhuis]

I also left a comment on nodejs/node#16234 but if you look at the output from nm, there are a lot of symbols in there that probably have no business being weak:

...
000000000002bafb W napi_value__* Napi::details::WrapCallback<Napi::RegisterModule(napi_env__*, napi_value__*, Napi::Object (*)(Napi::Env, Napi::Object))::{lambda()#1}>(Napi::RegisterModule(napi_env__*, napi_value__*, Napi::Object (*)(Napi::Env, Napi::Object))::{lambda()#1})
0000000000037078 W Napi::details::AccessorCallbackData<Napi::Value (*)(Napi::CallbackInfo const&), void (*)(Napi::CallbackInfo const&)>::GetterWrapper(napi_env__*, napi_callback_info__*)
0000000000037159 W Napi::details::AccessorCallbackData<Napi::Value (*)(Napi::CallbackInfo const&), void (*)(Napi::CallbackInfo const&)>::SetterWrapper(napi_env__*, napi_callback_info__*)
000000000002f638 W Napi::External<int>::New(napi_env__*, int*)
000000000002f302 t Napi::External<int> Napi::External<int>::New<(anonymous namespace)::CreateExternalWithFinalize(Napi::CallbackInfo const&)::{lambda(Napi::Env, int*)#1}>(napi_env__*, int*, (anonymous namespace)::CreateExternalWithFinalize(Napi::CallbackInfo const&)::{lambda(Napi::Env, int*)#1})
000000000002f3e4 t Napi::External<int> Napi::External<int>::New<(anonymous namespace)::CreateExternalWithFinalizeHint(Napi::CallbackInfo const&)::{lambda(Napi::Env, int*, char*)#1}, char>(napi_env__*, int*, (anonymous namespace)::CreateExternalWithFinalizeHint(Napi::CallbackInfo const&)::{lambda(Napi::Env, int*, char*)#1}, char*)
000000000002f7b8 W Napi::External<int>::External(napi_env__*, napi_value__*)
...