-
Notifications
You must be signed in to change notification settings - Fork 82
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
Stable sodium #104
base: master
Are you sure you want to change the base?
Stable sodium #104
Conversation
… change over time.
I suspect this build fails because the jni library isn't found by |
Thank you for the pull request. My comments are below.
This was done due to nuances of loading the library using System.loadlibrary. If the library can be loaded ok and eliminate the build error then I would be happy to not install to the system location.
Thanks.
The various build scripts were the original build system. Gradle was a recent addition. The build scripts were kept as legacy, can be eventually deprecated and eventually removed.
There were some strange upstream changes that caused errors when updating the submodule. Though can try again the hard reset. |
There are a bunch of changes here:
sudo
is required is a red flag for this. A lot of this stuff was potentially overwriting existing system files (such as my local and independent install of libsodium through homebrew).LIBSODIUM_FULL_BUILD
is now required but was not consistently set for all builds & platforms.build.sh
's native build was conflicting with its android architecture builds. I've updated it to matchgradle.build
's approach, which is to build it into thehost
prefix. Why is this build code duplicated? We should probably killbuild.sh
?libsodium
& refetching on build. This was pointlessly excessive & expensive. Most likely, this was necessary because ofbuild.sh
's bad behavior of building the native build without a prefix (see [3]).