Changes back into upstream?

[ralphtheninja]

Have you thought anything about or tried to get the changes back into node-gyp? We're trying to make prebuilt binaries for leveldown on arm systems. It would obviously be nice to support nodejs-mobile by doing so and we'd like to stick with node-gyp as much as possible.

cc @vweevers

[jaimecbernardo]

Hi @ralphtheninja ,

It's not part of the plans, currently. Our understanding is that these changes would have some difficulty being merged, since they are for Android, which is not "officially" supported and iOS, which is not supported at all.

The build process for native modules for nodejs-mobile for Android also are different than the ones that would work with node on Android, since they need to be linked with the nodejs-mobile binaries at build time to get a ELF header entry for libnode.so, or Android won't look for the linked functions there at runtime (this is a difference from how Linux distros normally behave).

So you'd probably still need to have a distinct binary for nodejs-mobile, depending on how the other systems behave on having an entry for libnode.so in a shared library when trying to load it. Haven't tested this scenario yet.

I hope this is helpful.

[jaimecbernardo]

If it's Android only we're talking about, this linking might work with node-gyp using nodejs-mobile's headers, since the linking libraries are defined in the common.gypi file contained in the headers:
https://github.com/janeasystems/nodejs-mobile/blob/b57420f7755ae72b8e44aeb5d25905dadf7b71fa/common.gypi#L412-L433

In case you want to give it a try.

[ralphtheninja]

The build process for native modules for nodejs-mobile for Android also are different than the ones that would work with node on Android, since they need to be linked with the nodejs-mobile binaries at build time to get a ELF header entry for libnode.so, or Android won't look for the linked functions there at runtime (this is a difference from how Linux distros normally behave).

Aaah good to know. So we probably need to take this into account when making prebuilt binaries for leveldown. I'm guessing we want to support nodejs-mobile primarily; it's the only node/android project that I know of or that's an active project.

[blueye]

@ralphtheninja have you build leveldown successfuly using nodejs-mobile on Android?

[vweevers]

@blueye We ended up building against node core, see https://github.com/Level/leveldown#notes

[blueye]

@vweevers It did not work for me. I use pouchdb which depends on leveldown. When I run pouchdb on Android using nodejs-mobile, some errors occur as below. My project builds on windows and then I copy it into Android with corresponding leveldown library. Could you give me some suggestions?

internal/modules/cjs/loader.js:1207
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^
Error: dlopen failed: cannot locate symbol "napi_create_external" referenced by "/data/data/xxxx/files/nodejs-project/prebuilds/android-arm/node.napi.armv7.node"...
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1207:18)
    at Module.load (internal/modules/cjs/loader.js:1001:32)
    at Function.Module._load (internal/modules/cjs/loader.js:900:14)
    at Module.require (internal/modules/cjs/loader.js:1043:19)
    at require (internal/modules/cjs/helpers.js:77:18)

[vweevers]

If you're using nodejs-mobile then you need to build leveldown from source, otherwise it will use a prebuilt binary that was built for node core. If you're using npm, you can pass --build-from-source, e.g. npm install --build-from-source or npm install pouchdb --build-from-source.

[blueye]

@vweevers Thanks for your suggestion. I will try it later.

[jaimecbernardo]

Hi @blueye ,
Please check #7

[Linoy339]

@blueye
Did u get a solution? I am also facing the same issue :
Error: dlopen failed: cannot locate symbol "napi_get_global" referenced by "/data/data/digital.lamp.mindlamp/files/lampBuild/api/node_modules/leveldown/prebuilds/android-arm64/node.napi.armv8.node"...