Level/level-rocksdb

Error: Could not locate the bindings file.

mrkent opened this issue · 10 comments

mrkent commented

I'm trying to put my code on an AWS ubuntu ec2 instance. Built rocksdb via make static_lib in ~/rocksdb.

When I try to start my express server, I get the following error. I'm not sure how to hook rocks up properly. Also, why is leveldown.node available in node_modules on my localmachine, but not on the ec2 after an npm install?

ubuntu@ip:~/myapp$ node server/index.js
/home/ubuntu/myapp/node_modules/bindings/bindings.js:99
  throw err
  ^

Error: Could not locate the bindings file. Tried:
 → /home/ubuntu/myapp/node_modules/rocksdb/build/leveldown.node
 → /home/ubuntu/myapp/node_modules/rocksdb/build/Debug/leveldown.node
 → /home/ubuntu/myapp/node_modules/rocksdb/build/Release/leveldown.node
 → /home/ubuntu/myapp/node_modules/rocksdb/out/Debug/leveldown.node
 → /home/ubuntu/myapp/node_modules/rocksdb/Debug/leveldown.node
 → /home/ubuntu/myapp/node_modules/rocksdb/out/Release/leveldown.node
 → /home/ubuntu/myapp/node_modules/rocksdb/Release/leveldown.node
 → /home/ubuntu/myapp/node_modules/rocksdb/build/default/leveldown.node
 → /home/ubuntu/myapp/node_modules/rocksdb/compiled/8.10.0/linux/x64/leveldown.node
    at bindings (/home/ubuntu/myapp/node_modules/bindings/bindings.js:96:9)
    at Object.<anonymous> (/home/ubuntu/myapp/node_modules/rocksdb/leveldown.js:3:36)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.wrappedLoad [as _load] (/home/ubuntu/myapp/node_modules/newrelic/lib/shimmer.js:372:38)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
vweevers commented

but not on the ec2 after an npm install

Could you share the output of npm install?

mrkent commented

I reorganized my package.json and reinstalled and problem fixed itself. Thanks @vweevers.

I'm still unclear on how the this package knows where to find rocksdb after I built using make static_lib. Feel free to close this.

vweevers commented

I reorganized my package.json and reinstalled and problem fixed itself.

👍

I'm still unclear on how the this package knows where to find rocksdb after I built using make static_lib

Building manually is not necessary; the npm package has an install script that either downloads a prebuilt binary or compiles it, depending on the platform.

mrkent commented

@vweevers is it installed in production or debug mode?

vweevers commented

Not sure what you mean.

mrkent commented

According to the fb repo:

Important: If you plan to run RocksDB in production, don't compile using default make or make all. That will compile RocksDB in debug mode, which is much slower than release mode.

vweevers commented

I would guess release mode, cc-ing @ralphtheninja @filoozom to confirm.

ralphtheninja commented

We're not using make to build it, it's node-gyp.

vweevers commented

@ralphtheninja I noticed in the makefile that RocksDB, besides the traditional debug and release mode, has a DEBUG_LEVEL that affects compiler flags: Makefile#L30.

In our builds, do we end up calling the compiler with the same flags?

ralphtheninja commented

Here's an excerpt from npm i --verbose when building rocksdb:

  g++ '-DNODE_GYP_MODULE_NAME=leveldb' '-DUSING_UV_SHARED=1' '-DUSING_V8_SHARED=1'
 '-DV8_DEPRECATION_WARNINGS=1' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' 
'-DSNAPPY=1' '-DROCKSDB_PLATFORM_POSIX=1' '-DOS_LINUX=1' '-DROCKSDB_LIB_IO_POSIX=1' 
-I/home/lms/.node-gyp/11.3.0/include/node -I/home/lms/.node-gyp/11.3.0/src -I/home/lms/.node-gyp/11.3.0/deps/openssl/config -I/home/lms/.node-gyp/11.3.0/deps/openssl/openssl/include -I/home/lms/.node-gyp/11.3.0/deps/uv/include -I/home/lms/.node-gyp/11.3.0/deps/zlib -I/home/lms/.node-gyp/11.3.0/deps/v8/include -I../deps/leveldb/leveldb-rocksdb -I../deps/leveldb/leveldb-rocksdb/include -I../deps/snappy/linux -I../deps/snappy/snappy-1.1.7  -fPIC -pthread -Wall -Wextra -Wno-unused-parameter -m64 -std=c++0x -Wno-sign-compare -Wno-unused-but-set-variable -O3 -fno-omit-frame-pointer -std=gnu++1y -MMD -MF ./Release/.deps/Release/obj.target/leveldb/deps/leveldb/leveldb-rocksdb/db/auto_roll_logger.o.d.raw   -c -o Release/obj.target/leveldb/deps/leveldb/leveldb-rocksdb/db/auto_roll_logger.o ../deps/leveldb/leveldb-rocksdb/db/auto_roll_logger.cc

So it seems we're not setting D_DEBUG_LEVEL to anything, which means it defaults to 1.