lyubo / react-native-sodium

ISC License
61 stars 46 forks source link

This file seems to randomly disappear causing build issues. #35

Open khan-zia opened 4 years ago

khan-zia commented 4 years ago

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.

khan-zia commented 4 years ago

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.

tasn commented 4 years ago

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.

khan-zia commented 4 years ago

Hopefully @lyubo will figure it out.

lyubo commented 4 years ago

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.

tasn commented 4 years ago

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:

  1. Have a working project that builds correctly.
  2. yarn add some-other-package

It fails.

Not sure if this is what's going on, but maybe a clue.

khan-zia commented 4 years ago

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.

lyubo commented 4 years ago

Can you try with react-native-sodium@0.3.6 (i.e the version with gpg)?

khan-zia commented 4 years ago

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.

tasn commented 4 years ago

@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?

lyubo commented 4 years ago

@tasn , last project I've used this library in used npm as package manager, so I can't tell if it is yarn related.

khan-zia commented 4 years ago

@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 commented 4 years ago

@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.

tbrent commented 4 years ago

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.

tbrent commented 4 years ago

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.

tasn commented 4 years ago

Just had it again on a new project... :|

khan-zia commented 4 years ago

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.

lyubo commented 4 years ago

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.

tasn commented 4 years ago

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.

lyubo commented 4 years ago

Latest react-native-sodium (0.3.9) had been published about an hour ago.

tasn commented 4 years ago

Ah, I missed that. I just upgraded, will keep an eye out for issues.

tasn commented 4 years ago

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.

lyubo commented 4 years ago

Post the exact error message, please! Xcode version used to compile library for iOS is 11.7.

lyubo commented 4 years ago

@tsan, @khan-zia, @tbrent Please give some more context - yarn version, npm version, OS version, RN version. Also exact steps to reproduce this issue.

tasn commented 4 years ago

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.

lyubo commented 4 years ago

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

tasn commented 4 years ago

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.

tasn commented 4 years ago

@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.

lyubo commented 4 years ago

@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

tasn commented 4 years ago

@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.

lyubo commented 4 years ago

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.

tasn commented 4 years ago

Did you close it by mistake? As the issue is still here. Also, I disagree about your conclusion, we can just extract if and only if the directory is missing, so if people build their own, they won't be affected.

lyubo commented 4 years ago

yes, sorry

tgreco commented 2 years ago

Running into this issue.