-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic fallback to use LevelDB native binary installed by OS package manager, instead of one bundled (leveldbjni-all) #90
Comments
So leveldbjni is not the same as the leveldb lib. leveldbjni contains the lelveldb lib statically compiled in and also all the JNI wrapper code used to access leveldb. In theory you could make it work if you did |
Got it, I understand it better now; thanks for clarifying. (I've edited the original issue description to clarify that this is about it working O-O-B in connection with e.g. a
It appears that there IS a RPM already (see https://koji.fedoraproject.org/koji/packageinfo?packageID=18435; thanks to @skitt for pointed me to), but that's one of those RPM-for-Java-JAR thingies - that package, currently, does not directly provide a leveldbjni.so in e.g. /lib64, so that e.g. ldconfig & Co. can find it. I say not directly provide because that RPM does have the SO in it somewhere (in /META-INF/native/linux64/ inside its leveldbjni-all.jar = leveldbjni-linux.jar which it installs into [/usr]/lib/java/), but that's... justement not what one would want, in this context, IMHO. Just for future reference and repeatability for testing, check this out, if interested:
Note that this is different from e.g. the this or any other lib package (FTR: This issue is now not about the leveldb anymore, that's separate and not directly related to leveldbjni.)
|
OK, just as a POC, the following isn't the expected end game, just proof that the approach would be viable, if it were industrialized by e.g. an RPM which correctly installed required native binary shared libraries: For this POC we HAVE to manually install leveldb (see below), if this was industrialized then leveldbjni would have a dependency on leveldb and this would not be needed anymore; and we install leveldbjni just to grab the *.so from inside it, but as explained above that package (currently) does not actually correctly install the *.so in a usable form:
if we now add this to the leveldbjni/leveldbjni-tests/pom.xml to make it use the *.so from /tmp:
then the If we did about without installing leveldb, then it would still fail with
|
#91 proposes some doc clarification related to this. Re. RPM, see https://bugzilla.redhat.com/show_bug.cgi?id=1420383 => https://bugzilla.redhat.com/show_bug.cgi?id=1420433 |
Self closing as timed out, as I have no intention to continue working on this. Background, FTR: due to https://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI, it appears to be much more difficult than I originally thought it would be to get a RPM which just has the libleveldbjni.so in /lib64/ instead of wrapped inside /lib/java/leveldbjni-linux.jar ... I personally think this is fundamentally wrong, but it appears changing this would be bigger discussion than I'm motivated to have. |
I am getting this error in rocksdbjni,i am using latest rocksdb 5.9.2,with rocksdb 3.0 i am able to pass all test cases but it is failing with latest version. Running org.fusesource.rocksdbjni.test.DBTest |
@anuscool why are you commenting about that in this (closed) issue on the leveldbjni project? Probably more suitable for the https://github.com/fusesource/rocksdbjni/issues project? |
For use cases such as https://bugs.opendaylight.org/show_bug.cgi?id=7742,
the goal of this issue would to be make this kind of set-up work out of the box in leveldbjni (where "out of the box" = "just work", without having to set anything like custom environment variables, -D system properties and the like):
I suspect that this may require a little bit of work in http://fusesource.github.io/hawtjni/ ? The above currently doesn't work yet (fails with
java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no leveldbjni64-99-master-SNAPSHOT in java.library.path, no leveldbjni-99-master-SNAPSHOT in java.library.path, no leveldbjni in java.library.path] at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:187)
); probably because HawtJNI's Library only checks in the classpath's META-INF/native/, but cannot by itself detect native binary *.so libs installed by OS package manager?The text was updated successfully, but these errors were encountered: