Closed rob-odwyer closed 1 year ago
@kawamuray It looks like the ubuntu-18.04 build got stuck waiting for a runner.
I could just merge if you're ok with running it again on the main branch, or if you can kick off another build maybe it'll go through this time.
FYI, ubuntu-18.04
has been deprecated. https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/
I've updated to use Ubuntu 20.04, which hopefully won't already be deprecated by the time the workflow runs.
CI with the previous commit didn't start actually: https://github.com/kawamuray/wasmtime-java/actions/runs/5324587129/jobs/9654650389
Hey @rob-odwyer - Did you try using the 0.15.0 release jar ? When I try, I get the same error from the new version as well
java.lang.UnsatisfiedLinkError: /tmp/libwasmtime_jni_0.15.0_linux10664629044671527944.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/libwasmtime_jni_0.15.0_linux10664629044671527944.so)
@luckoseabraham Looks like the second gradle build in the publish step actually re-generates the linux shared lib, which replaces the compatible one from the build step. I'm working on another change that fixes this along with improving the GLIBC compatibility further, will keep you posted.
@luckoseabraham I believe this PR should fix the issue: https://github.com/kawamuray/wasmtime-java/pull/50 and I've tested the shared lib that actually ends up inside the JAR this time 😄
That's awesome @rob-odwyer. Thank you !
The current published JNI build requires glibc >= 2.32 to be installed, otherwise you get this error:
From our testing, we've found that just building against an older version of glibc will result in a more compatible build, since later installs will still include support for the older glibc versions. The easiest way to do that is to use the older
ubuntu-18.04
runner, which will result in linking againstGLIBC_2.27
. I've included a debug step here to show that, but I'm happy to remove it if required.I've tested this out myself via a local actions runner and it doesn't seem to introduce any incompatibilities. In order to actually depend on the resulting build from our library however, it's much simpler to have a new release made from this project, instead of a manually included JAR.