java.lang.UnsatisfiedLinkError on v4 in Windows
JordanMLee opened this issue · 2 comments
Getting java.lang.UnsatisfiedLinkError: No native resource found at /windows-x64/libh3-java.dll when trying to load dlls when calling H3Core.newInstance() on V4.
It appears that the H3 V4 builds on maven and other sites are missing the specific relative path /windows-x64/libh3-java.dll. I’d run into this same issue when trying out the release candidates. V3 builds had the [os]-[architecture] path. You can see the difference below.
| V4 | V3 |
|---|---|
 |
 |
When initializing with H3Core.newInstance(), the class loader searches for [os]-[architecture]. If you manually change the windows dll naming back to V3 (remove "-static"), it'll work.
Looks like there weren't any changes in the build script since last release. Curiously if it's possible to get the naming switched back, wondering if this is an issue with Dockcross (if you still use that for cross compiling).
According to https://github.com/uber/h3-java/blob/master/src/main/c/h3-java/build-h3.sh#L185 it's supposed to be placed in windows-x64, but it looks like a bug in the script prevented that: https://github.com/uber/h3-java/actions/runs/2913778419/jobs/4641930675#step:6:3650 The script should have been [ "$image" = windows-static-x64 ] (note = instead of -eq.)
This wasn't caught in the script because set -ex doesn't fail the entire script if the conditional fails - this wouldn't work since the conditional has to evaluate to false sometimes.
This also wasn't caught because while we have Windows tests, they build the native library in MSVC rather than using the cross compiled version. Perhaps we could build once and then run the CI suite in order to validate the library? A more immediate test we could add is asserting the right set of resources are present in the JAR.
Edit: I retitled the issue to include Windows to help anyone skimming for relevant issues.
4.0.1 is now being released which should fix this. Please let me know if the issue remains