Open ccjernigan opened 8 months ago
Hey @ccjernigan! Thanks for spotting the issue! I am very unexperienced in packaging JNI libraries. Together with @superkelvint we've been trying to fix those, but the iteration cycle is super slow. Are you familiar with the process? Can you help us patch it?
I'm not a JNI expert, although maybe we can figure this out together.
How are you iterating currently? I like to publish/consume libraries from Maven local (~/.m2
) to help troubleshoot with packaging of libraries.
It also looks like this issue may be platform-specific. With a GitHub Actions workflow, it works on Linux but not Windows or macOS. For the macOS issue, I confirmed the problem occurs on Intel and M1 so it isn't a simple architecture issue either.
See https://github.com/ccjernigan/search/actions/runs/6907563003
There's only a single .so
file packaged into the JAR. Shouldn't there be either multiple JAR files (on per platform) or multiple .so files within the JAR file? Basically, don't we need a matrix of native libraries for OS (Windows, macOS, and Linux) and architecture (ARM and x86)?
Yes, @ccjernigan, we need a matrix of JARs, but I am not sure about how to configure Bazel and GitHub CI for that output.
I am currently overwhelmed with clustering and dimensionality reduction functionality and the upcoming v3 release, so if you could contribute patches, that would help us a lot!
we are also looking for the same fix while using to usearch + java binding run on the M1 mac.
I believe #407 may be fixing this issue, @patedhav and @ccjernigan 🤗
Thanks to @mccullocht 🙌
I'm planning to merge into main
once I understand where the root cause of replacements bug comes from.
@ashvardanian @mccullocht #407 seems to be Index.get(int key)
throwing exception issue. Does it also include building jar with MacOS M1 .so1 file?
@patedhav seems so, as @mccullocht has added a Clang build and fixed library name resolution to fetch .dylib
on MacOS. Correct me if I'm wrong 🤗
@ashvardanian thanks for the update, looking forward to get it to main and java jar release!
Describe the bug
Touching
Index
causes the static initializer for loading the native library to execute. This doesn't seem to be working correctly.Results:
usearch.zip
Steps to reproduce
Using the attached
./gradlew run
Expected behavior
Application runs
USearch version
2.8.12
Operating System
macOS Sonoma 14.1.1
Hardware architecture
Arm
Which interface are you using?
Other bindings
Contact Details
No response
Is there an existing issue for this?
Code of Conduct