Docker issues.

[chrisjenx]

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:

co.libly.resourceloader.ResourceLoaderException at SealedBoxEncryptorKtTest.kt:15
        Caused by: java.io.FileNotFoundException at SealedBoxEncryptorKtTest.kt:15

[chrisjenx]

Works find on windows/osx

[gurpreet-]

Hi @chrisjenx,

Thank you for raising this. So it's struggling to unpack in a docker image 🤔

1. What is the base docker image you're running? Just so I can replicate this.
2. What files were unpacked?

[chrisjenx]

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.

[gurpreet-]

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)

[gurpreet-]

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:

1. Use a docker base that does in include it. That is, use FROM openjdk:8-jre-slim.
2. 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
3. Or alternatively RUN apk update && apk add --no-cache gcompat

Hope that works 👍

[chrisjenx]

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 ***@***.***> 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: 1. Use a docker base that does in include it. That is, use FROM openjdk:8-jre-slim. 2. 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 3. 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 <#2>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI5DMOEUGFTVGWZZQSWYQ3QUHFTVANCNFSM4JJ23FLA> .