libusdt-build.sh tries to use the wrong node

[davepacheco]

When installing a package with dtrace-provider as a dependency, it tries to use the wrong node and ends up building the wrong kind of shared object:

dap@4a98263f marlin $ which node
/home/dap/marlin/build/node/bin/node
dap@4a98263f marlin $ node --version
v0.8.14
dap@4a98263f marlin $ which npm
/home/dap/marlin/build/node/bin/npm
dap@4a98263f marlin $ npm --version
1.1.65


dap@4a98263f marlin $ npm install -g bunyan
npm http GET https://registry.npmjs.org/bunyan
npm http 304 https://registry.npmjs.org/bunyan
npm http GET https://registry.npmjs.org/dtrace-provider/0.2.4
npm http 304 https://registry.npmjs.org/dtrace-provider/0.2.4

> [email protected] install /home/dap/install/lib/node_modules/bunyan/node_modules/dtrace-provider
> node-gyp rebuild

make: Entering directory `/home/dap/install/lib/node_modules/bunyan/node_modules/dtrace-provider/build'
  ACTION binding_gyp_libusdt_target_build_libusdt .
Using node: /home/dap/install/bin/node
libusdt-build.sh: line 23: /home/dap/install/bin/node: not found
Building libusdt for 
make[1]: Entering directory `/home/dap/install/lib/node_modules/bunyan/node_modules/dtrace-provider/libusdt'
rm -f *.gch
rm -f *.o
rm -f libusdt.a
rm -f test_usdt
rm -f test_usdt32
rm -f test_usdt64
gcc -O2 -fPIC -m64   -c -o usdt.o usdt.c
gcc -O2 -fPIC -m64   -c -o usdt_dof_file.o usdt_dof_file.c
gcc -O2 -fPIC -m64 -o usdt_tracepoints.o -c usdt_tracepoints_x86_64.s
gcc -O2 -fPIC -m64   -c -o usdt_probe.o usdt_probe.c
gcc -O2 -fPIC -m64   -c -o usdt_dof.o usdt_dof.c
gcc -O2 -fPIC -m64   -c -o usdt_dof_sections.o usdt_dof_sections.c
rm -f libusdt.a
ar cru libusdt.a usdt.o usdt_dof_file.o usdt_tracepoints.o usdt_probe.o usdt_dof.o usdt_dof_sections.o 
/bin/true libusdt.a
make[1]: Leaving directory `/home/dap/install/lib/node_modules/bunyan/node_modules/dtrace-provider/libusdt'
  TOUCH Release/obj.target/libusdt.stamp
  CXX(target) Release/obj.target/DTraceProviderBindings/dtrace_provider.o
  CXX(target) Release/obj.target/DTraceProviderBindings/dtrace_probe.o
  SOLINK_MODULE(target) Release/obj.target/DTraceProviderBindings.node
ld: warning: file /home/dap/install/lib/node_modules/bunyan/node_modules/dtrace-provider/libusdt/libusdt.a(usdt.o): wrong ELF class: ELFCLASS64
  SOLINK_MODULE(target) Release/obj.target/DTraceProviderBindings.node: Finished
  COPY Release/DTraceProviderBindings.node
make: Leaving directory `/home/dap/install/lib/node_modules/bunyan/node_modules/dtrace-provider/build'
/home/dap/install/bin/bunyan -> /home/dap/install/lib/node_modules/bunyan/bin/bunyan
[email protected] /home/dap/install/lib/node_modules/bunyan
└── [email protected]

The problem is that libusdt-build.sh is using npm_config_prefix to determine where node is, but that's not what prefix refers to. According to the npm documentation:

   prefix
       o   Default: node's process.installPrefix

       o   Type: path



       The location to install global items.  If set on the command line, then
       it forces non-global commands to run in the specified folder.

Note that the default matches node's install prefix, but the user can set this to anything they want to install items somewhere other than where node is installed, which is what I had done here.

The resulting binary fails to load dtrace-provider since it has the wrong ELF type for my 32-bit node.

[trentm]

So, at best, my earlier suggestion to use npm_install_prefix to try to find the running node during a npm install was a guess.

Ideally, npm should provide something in the environment to identify the relevant node.

Either way, I think we should have "libusdt-build.sh" fallback to which node for the node to use. Suggested patch for that: https://gist.github.com/a4df7874c339edcf3df4

@chrisa thoughts?

[chrisa]

@trentm looking at how things were before #24, in v0.2.3, we relied entirely on the PATH by just invoking "node". Was that causing you problems with Node 0.6, or was the issue just the use of process.config?

@davepacheco from what you show in this issue above, relying on PATH would work for your situation - does v0.2.3 build ok for you?

[chrisa]

Based on this commit to npm:

isaacs/npm@8985944

it seems that just relying on PATH is the right thing to do. I'm planning to just remove the use of $npm_config_prefix, and invoke "node" directly in libusdt-build.sh.

[trentm]

@chrisa It was just the Python usage.... along with some confusion as to whether npm did (a) require the used node to be first on the PATH and (b) whether it did so itself. Sounds like just using 'node' (first on PATH) would work.

[chrisa]

I've reverted to just using node from PATH. I'll do a release when the changes here to take advantage of chrisa/libusdt#5 are ready.

[chrisa]

dtrace-provider 0.2.5 has this fix.