Closed chrisjenx closed 3 years ago
Works find on windows/osx
Hi @chrisjenx,
Thank you for raising this. So it's struggling to unpack in a docker image 🤔
Just to clarify, I don't think this is libly's fault, but does worry me, that it could affect some docker containers. For us we're using a circleci/android container, I'm struggling to get a full stack trace and see what the tmp structure looks like. It's more of an FYI for other people.
Hi @chrisjenx,
Just realised you're the author of Calligraphy! I've used it so many times in my Android projects so thank you very much for that! 😁
I made myself a very brief docker container and tested it. It does indeed crash inside docker containers. This is not ideal at all and I will try and fix it. Example stacktrace:
Exception in thread "main" co.libly.hydride.utils.LibraryLoadingException: Failed to load the library using /tmp/hydride/libhydrogen.so
at co.libly.hydride.utils.LibraryLoader.loadLibrary(LibraryLoader.java:182)
at co.libly.hydride.utils.LibraryLoader.loadBundledLibrary(LibraryLoader.java:152)
at co.libly.hydride.utils.LibraryLoader.loadLibrary(LibraryLoader.java:116)
at co.libly.hydride.Hydrogen.<init>(Hydrogen.java:30)
Just found a solution. It seems that if you are using alpine
images they don't include glibc
. The solution provided here is very helpful.
So to solve this issue you can do one of 3 things it seems:
FROM openjdk:8-jre-slim
.glibc
via RUN apk update && apk add --no-cache libc6-compat
RUN apk update && apk add --no-cache gcompat
Hope that works 👍
Awesome, thanks for looking into this. That's great to hear! We moved to Android tests for this specifically but if we do something on the backend for this I'll give this a go!
Hopefully if anyone else has a similar issue they will see this.
On Sun, Nov 17, 2019, 4:11 PM Gurpreet Paul notifications@github.com wrote:
Just found a solution. It seems that if you are using alpine images they don't include glibc. The solution provided here https://stackoverflow.com/questions/50288034/unsatisfiedlinkerror-tmp-snappy-1-1-4-libsnappyjava-so-error-loading-shared-li/ is very helpful.
So to solve this issue you can do one of 3 things it seems:
- Use a docker base that does in include it. That is, use FROM openjdk:8-jre-slim.
- If you don't want to switch your base image then you can Install glibc via RUN apk update && apk add --no-cache libc6-compat
- Or alternatively RUN apk update && apk add --no-cache gcompat
Hope that works 👍
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libly/resource-loader/issues/2?email_source=notifications&email_token=AAI5DMMJ6IZJB6YUIWCKDS3QUHFTVA5CNFSM4JJ23FLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEIY5UY#issuecomment-554798803, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5DMOEUGFTVGWZZQSWYQ3QUHFTVANCNFSM4JJ23FLA .
Not sure why, struggling to dig into it, but resource loader seems to struggle to unpack resources when running within a docker instance.
I'm trying to get the full stack, but it looks like it never unpacks from the jar correctly: