Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine for which ARM flavors we want prebuilds #574

Closed
4 of 6 tasks
vweevers opened this issue Dec 27, 2018 · 12 comments · Fixed by #587
Closed
4 of 6 tasks

Determine for which ARM flavors we want prebuilds #574

vweevers opened this issue Dec 27, 2018 · 12 comments · Fixed by #587
Labels
discussion Discussion

Comments

@vweevers
Copy link
Member

vweevers commented Dec 27, 2018

Because 1) we can't test them all 2) Travis builds cost time 3) maintenance costs time 4) prebuilds increase npm package size. So for each flavor, there must be a real target audience.

@ahdinosaur @staltz and others: could you share which flavor(s) you need, ideally backed by a specific use case (e.g. scuttlebutt on android)? Thanks!

Flavors to choose from:

  • prebuildify-cross --platform=linux --arch=arm --arm-version=5
  • prebuildify-cross --platform=linux --arch=arm --arm-version=6
  • prebuildify-cross --platform=linux --arch=arm --arm-version=7
  • prebuildify-cross --platform=linux --arch=arm64
  • prebuildify-cross --platform=android --arch=arm --arm-version=7
  • prebuildify-cross --platform=android --arch=arm64
@ahdinosaur
Copy link

i'm keen for linux arm64, as that's the architecture i plan to run for PeachCloud! 🍑 ☁️

i also think linux armv7 is worth publishing, as it's the standard architecture for anybody using a Raspberry Pi 2 or 3 with Raspbian. but we could also wait for someone who has a specific use case.

i should also note that android armv6 is not an option (my mistake): prebuild/prebuildify-cross@1ee1e4b

❤️

@ralphtheninja
Copy link
Member

i also think linux armv7 is worth publishing, as it's the standard architecture for anybody using a Raspberry Pi 2 or 3 with Raspbian. but we could also wait for someone who has a specific use case.

Covering Raspberry Pi is a really good use case since compiling on that platform is super slow.

i'm keen for linux arm64, as that's the architecture i plan to run for PeachCloud! peach cloud

Lets do this then as well. I'm curious, why did you pick this architecture? What are you running it on and where? Your own hosting? Can we run some leveldown unit tests on it as well? :)

It would be really cool to cover android as well. Which version of arm would that be? android-arm64?

@vweevers
Copy link
Member Author

i should also note that android armv6 is not an option

Removed it from the list, thanks.

@ahdinosaur
Copy link

I'm curious, why did you pick this architecture? What are you running it on and where? Your own hosting?

PeachCloud is really just a fancy (product) name for a Raspberry Pi setup to run Scuttlebutt: %9NCyTf+oBxG0APlXRCKtrGZj3t+i+Kp3pKPN1gtFX2c=.sha256. i decided to skip Rasbian (which is 32-bit) and roll my own Debian images to target the latest Raspberry Pi 3's using arm64. still early days, been mostly working on cross-compiling images and packages, so that's why i happened to have the knowledge to be helpful here. ☀️

@staltz
Copy link
Contributor

staltz commented Jan 1, 2019

Hi! I haven't used prebuildify-cross, so not sure how exactly --platform=android is used, but in gyp jargon, I'm sure that Level on mobile (e.g. Scuttlebutt on mobile) needs OS='android' configured for gyp so that it gets built for Android, using these flags

["OS == 'android'", {

E.g. here's the gyp (from nodejs-mobile-gyp) logs that I get on a correct build of leveldown for Android:

gyp info spawn /usr/bin/python2
gyp info spawn args [ './manyverse/node_modules/nodejs-mobile-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make-android',
gyp info spawn args   '-I',
gyp info spawn args   './manyverse/android/build/nodejs-native-assets-temp-build/nodejs-native-assets-armeabi-v7a/nodejs-project/node_modules/leveldown/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   './manyverse/node_modules/nodejs-mobile-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   './manyverse/node_modules/nodejs-mobile-react-native/android/libnode/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=./manyverse/node_modules/nodejs-mobile-react-native/android/libnode/',
gyp info spawn args   '-Dnode_gyp_dir=./manyverse/node_modules/nodejs-mobile-gyp',
gyp info spawn args   '-Dnode_lib_file=./manyverse/node_modules/nodejs-mobile-react-native/android/libnode/$(Configuration)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=./manyverse/android/build/nodejs-native-assets-temp-build/nodejs-native-assets-armeabi-v7a/nodejs-project/node_modules/leveldown',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.' ]
gyp verb command build []
gyp verb build type Release
gyp verb architecture arm
gyp verb node dev dir ./manyverse/node_modules/nodejs-mobile-react-native/android/libnode/
gyp verb `which` succeeded for `make` /usr/bin/make
gyp info spawn make
gyp info spawn args [ 'V=1', 'BUILDTYPE=Release', '-C', 'build' ]
make: Entering directory './manyverse/android/build/nodejs-native-assets-temp-build/nodejs-native-assets-armeabi-v7a/nodejs-project/node_modules/leveldown/build'
  ./manyverse/android/build/standalone-toolchains/arm-linux-androideabi/bin/arm-linux-androideabi-clang++ '-DNODE_GYP_MODULE_NAME=leveldb' '-DUSING_UV_SHARED=1' '-DUSING_V8_SHARED=1' '-DV8_DEPRECATION_WARNINGS=1' '-DNODE_ENGINE="v8"' '-DNODE_ENGINE_V8' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-DSNAPPY=1' '-DLEVELDB_PLATFORM_POSIX=1' '-DOS_ANDROID=1' '-D_REENTRANT=1' '-D_GLIBCXX_USE_C99_MATH' -I./manyverse/node_modules/nodejs-mobile-react-native/android/libnode/include/node -I./manyverse/node_modules/nodejs-mobile-react-native/android/libnode/src -I./manyverse/node_modules/nodejs-mobile-react-native/android/libnode/deps/uv/include -I./manyverse/node_modules/nodejs-mobile-react-native/android/libnode/deps/v8/include -I../deps/leveldb/leveldb-1.20 -I../deps/leveldb/leveldb-1.20/include -I../deps/snappy/linux -I../deps/snappy/snappy-1.1.4  -fPIC -Wall -Wextra -Wno-unused-parameter -std=c++0x -Wno-sign-compare -fPIC -O3 -fno-omit-frame-pointer -fno-rtti -std=gnu++0x -MMD -MF ./Release/.deps/Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/builder.o.d.raw   -c -o Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/builder.o ../deps/leveldb/leveldb-1.20/db/builder.cc

I'm not familiar with prebuildify-cross, but I believe cross compilation for Android should use android/build/standalone-toolchains/arm-linux-androideabi/bin/arm-linux-androideabi-clang++ and related tooling from the Android SDK.

@vweevers
Copy link
Member Author

vweevers commented Jan 1, 2019

@staltz prebuildify-cross uses --platform for two things:

  1. Selecting a Docker image (together with --arch) (for example dockcross/android-arm)
  2. Passing it to the docker container as env variable PLATFORM, then running npm run prebuild in the container, which runs prebuildify, which will read process.env.PLATFORM (allow overriding platform for cross-compiling prebuild/prebuildify#20).

However, I don't know if prebuildify passes it to node-gyp (either explicitly or via env). Or if that's even necessary, because at that point, the environment has already been configured to use a certain toolchain (i.e. overriding node-gyp defaults).

I believe cross compilation for Android should use android/build/standalone-toolchains/arm-linux-androideabi/bin/arm-linux-androideabi-clang++ and related tooling from the Android SDK.

From what I gather dockcross/android-arm uses ./build/tools/make_standalone_toolchain.py to make a custom toolchain. Is it effectively the same toolchain?

@staltz
Copy link
Contributor

staltz commented Jan 1, 2019

From what I gather dockcross/android-arm uses ./build/tools/make_standalone_toolchain.py to make a custom toolchain. Is it effectively the same toolchain?

I assume it is the same. Good to know that dockcross/android-arm uses Android NDK.

@ralphtheninja
Copy link
Member

ralphtheninja commented Jan 1, 2019

I think we should just try and build some binaries and release another next premajor. Would be nice to be able to setup a test for this for some existing project on android using leveldown. I could set up a RPI to cover linux/armv7.

@christoph-verse
Copy link

Folks, I'm working on an iOS client for scuttlebutt so I also interested in an arm64 version. I am well versed in Mac and iOS development, but am a total node noob, so this whole bindings.js and .gyp files thing is a mystery to me. But, if I can help in any way to getting a leveldown.node that is iOS device and simulator compatible, please let me know. I'm investigating leveldown-mobile while inquiring here too.

@vweevers
Copy link
Member Author

I think the only remaining candidate to decide on is android-arm64. Anyone want/need it?

@staltz
Copy link
Contributor

staltz commented Jan 28, 2019

android-arm64

While armv7 code (what my project depends on) runs in arm64 devices, I suppose it will be useful to optimize for arm64, given the trend that arm64 will have in replacing armv7.

@vweevers
Copy link
Member Author

vweevers commented Feb 1, 2019

Thanks for your input all!

@vweevers vweevers closed this as completed Feb 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants