react-native-sodium
react-native-sodium copied to clipboard
lyubo
This file seems to randomly disappear causing build issues.
I might be missing something here and it might be an obvious reason, but so far it seems to be randomly loosing this file for Android at this location
".../node_modules/react-native-sodium/android/../libsodium/libsodium-android-i686/lib/libsodium.so".
The file is required inside react-native-sodium\android\CMakeLists.txt at the following copy operation
file(COPY ${PROJECT_SOURCE_DIR}/../libsodium/libsodium-android-${ARCH_DIR}/lib/libsodium.so DESTINATION "${PROJECT_SOURCE_DIR}/lib/${ANDROID_ABI}")
Please guide.
Update
@lyubo I have confirmed that the libsodium folder which gets unzipped from the precompiled gz, just magically disappears? any idea on why is that happening? It disappeared even after I manually extracted precompiled zip in there.
I'm experiencing the same. I'm not sure why it happens. One "solution" would be to change the build step (when built as a dep) to just extract the tar if doesn't exist. Not sure what the correct solution is though.
Give me some context pls. (package version android SDK version, etc.). Have you tried example application. New version is alinged with the most recent react-native and is working just fine.
I'm not sure it's exactly what's going on, but it seems to fail after installing another package (I'm using the yarn package manager).
To reproduce:
- Have a working project that builds correctly.
-
yarn add some-other-package
It fails.
Not sure if this is what's going on, but maybe a clue.
I am also using latest RN and SDK API 29. I don't have specific scenario either and I also use yarn. Every time it happens, I manually have to go to the folder and I extract the precompiled tar.
Alright. I will try that version and if the issue persists, I will update here. However, I don't know when it will happen again since I am not sure how to reproduce it. I guess if it doesn't happen for quite a while, then we can assume that it works. Meanwhile, I will keep an eye for pin pointing the issue.
@lyubo, it's unrelated to that gpg change because it's about installing this package a dep, not building libsodium from source.
Do you also use yarn? Could you maybe try reproducing like I mentioned above?
@tasn , last project I've used this library in used npm as package manager, so I can't tell if it is yarn related.
@tasn @lyubo , I have confirmed that this issue just happens right away after updating or adding with yarn. If you open the file browser and keep looking at it and run yarn command, the libsodium folder just disappears... This is very strange.
@tasn , last project I've used this library in used npm as package manager, so I can't tell if it is yarn related.
You can try reproducing it with npm too, the same way I and @khan-zia described.
Having the same issue. No libsodium.so at the expected location in node_modules for any of the architectures. Unzipping the .tgz manually shows the contents as they should be. Using yarn as well.
False alarm. Turns out Sublime was just not showing me .so files. The file is there, and it doesn't look like taking yarn actions does any damage to it. I am still facing an issue, but this is not it.
This is indeed a confirmed issue. Unfortunately it seems that it will require quite some time to dig through and pin point the problem. However, I think the time it will take will be considerably less if @lyubo could do it since he knows this library the best.
I've just updated the example application to newest RN and v0.3.9 of this package. I used yarn to build and run it on both iOS and Android emulators (I had used npm for example application until now). Unfortunately I could not reproduce this issue. Please, try to build with this new version, which was updated to version 1.0.18 of libsodium.
I tried with latest react-native-sodium and with latest RN. I created the app a few days ago. It doesn't happen immediately, but it happens after some usage.
I had to revert back to 0.3.8 because it wouldn't build with Xcode 11. I can't remember the exact error now, but it was something about bitcode incompatibility.
Post the exact error message, please! Xcode version used to compile library for iOS is 11.7.
@tsan, @khan-zia, @tbrent Please give some more context - yarn version, npm version, OS version, RN version. Also exact steps to reproduce this issue.
I don't have access to the build system so can't give you an exact error or version, but I think my Xcode is 11.4. There's nothing to investigate, the Xcode you built with is newer than mine (or maybe just incompatible, doesn't matter if newer or not) which was causing this.
As for the other error: OS: Latest Arch Linux yarn: 1.22.5 npm: 6.14.7 node: v14.13.0 react-native: 0.63.3
Exact steps: I already mentioned it above how I got to reproduce it, though I'm not sure whether it still happens consistently with those steps.
My attempt to reproduce:
1. npx react-native init test_rns && cd test_rns
2. yarn add react-native-sodium
3. ls -R1 node_modules/react-native-sodium/libsodium | wc -l (404)
4. yarn add react-navigation (randomly chosen)
5. ls -R1 node_modules/react-native-sodium/libsodium | wc -l (404, No files are missing)
OS: MacOS 10.15.6 yarn: 1.22.0 npm: 6.13.7 node: 12.13.1 react-native: 0.63.3
I haven't gotten it on RN for iOS yet, so make sure you build for Android. Also, as I said, it doesn't happen immediately. Try maybe removing the react-navigation from package.json by hand and then running yarn. It's an operation I do often (which switching branches) maybe that will cause it.
@lyubo: another idea on how to do it:
In a new project, install react-native-sodium and etebase (the dep I'm using). Use an old version of etebase. Doesn't matter which, just not latest. Make a git commit of this state (package.json and yarn.lock). Now install the latest etebase. I think it should still work now. Now, git stash to change back the changes you made to package.json and yarn.lock when you installed the latest etebase, and then run yarn (just like that, no parameters) so it syncs the deps again. I think that should do it.
@tasn: I still haven't try your suggestion, but running yarn (not yarn install) would possibly skip 'postinstall' hook, which is used to unzip precompiled.tgz file
@lyubo, yarn is an alias of yarn install, so I don't think it's that.
Actually, now that I re-read my description, it looks like yarn isn't calling the postinstall when the package is reinstalled but the version hasn't changed. I looked around and there seem to be a maybe related bug: https://github.com/yarnpkg/yarn/issues/5476 I wonder if there's maybe something more robust that can be done here, for example, make it as part of the ios/android build scripts to check if exists and if not, untar there.
The problem with hooking with build scripts is that if someone wants to build the library from source, and later these compiled files get deleted, users may end up with building with pre-compiled files, which apparently was not their intent.