[java] missing libjli.so

eydaimon

eydaimon

ideas appreciated

Code: 
$ java --version
/usr/local/linux-oracle-jdk1.8.0/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

$ ldd /usr/local/linux-oracle-jdk1.8.0/bin/java
/usr/local/linux-oracle-jdk1.8.0/bin/java:
        linux32_vdso.so.1 =>  (0xffffe000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x2806d000)
        libjli.so => not found
        libdl.so.2 => /lib/libdl.so.2 (0x28088000)
        libc.so.6 => /lib/libc.so.6 (0x2808d000)
        /lib/ld-linux.so.2 (0x28049000)

$ pkg version | ag jdk
linux-oracle-jdk18-8.121           =
 
First, totally unrelated but still good to know, you're probably better off letting pkg do the filtering for you. Saves server resources and all. So:

Code: 
peter@macron:~#pkg info -x jdk
openjdk8-8.121.13
Which is also my suggestion. Why not use OpenJDK instead of the Oracle package? Back in the days when several Linux distributions started to heavily push OpenJDK it was pretty bad in comparison to the official release from Sun, but times have drastically changed. Right now the changes are pretty much non-existent.

Anyway, this looks to me like an installation gone wrong:

Code: 
macron:/usr/local/openjdk8/bin $ ldd ./java
./java:
        libjli.so => /usr/local/openjdk8/bin/../lib/i386/jli/libjli.so (0x28076000)
        libz.so.6 => /lib/libz.so.6 (0x28083000)
        libthr.so.3 => /lib/libthr.so.3 (0x28098000)
        libc.so.7 => /lib/libc.so.7 (0x280b9000)
macron:/usr/local/openjdk8/bin $ pkg which /usr/local/openjdk8/bin/../lib/i386/jli/libjli.so
/usr/local/openjdk8/lib/i386/jli/libjli.so was installed by package openjdk8-8.121.13
(edit):

So maybe a bug in the java//linux-oracle-jdk18 port, but I'm not sure of course. Either way, my suggestion would be to do: # portmaster -o java/openjdk8 linux-oracle-jdk18. In other words: replace Linux Oracle JDK8 with OpenJDK8.
 
Sounds a bit bizarre to me, might be a good time to contact the maintainer about this. You could enforce this though, my trick with Portmaster would ensure that the dependencies get changed. Of course there are no guarantees, but it's easy enough to undo.

Maybe start by installing OpenJDK, change your path accordingly so that your system will prefer OpenJDK and then try again.

My other suggestion, though I know this won't help with the problem at hand, would be to ditch CrashPlan for something natively supported on FreeBSD. Of course I understand that this won't be an option if you actually pay for their services, but setting up a backup strategy should be pretty straightforward.

For example devel/awscli could be used to more easily access Amazon's AWS services, which would then allow you to get a Bucket there and store all the data accordingly using native tools. Downside would be having to set most of this up manually, but the upside would be that you wouldn't be fully depending on 1 single backup solution. If AWS doesn't cut it at some point for whatever reason you can easily swap them out for any other remote storage (this is assuming you're also using CrashPlan's storage services).
 
I did try with openjdk but the execution scripts for crashplan rely on oracle's jdk and puts the path as such when starting it. I don't really want to go too deep down that path and edit those excecution scripts
 
eydaimon said:
I did try with openjdk but the execution scripts for crashplan rely on oracle's jdk and puts the path as such when starting it. I don't really want to go too deep down that path and edit those excecution scripts
Click to expand...

Try editing the install.vars file in /usr/local/share/crashplan and change:

JAVACOMMON=/usr/local/linux-oracle-jdk1.8.0/bin/java
to
JAVACOMMON=/usr/local/openjdk8/bin/java

I was able to start CrashPlan after doing that.
 
You must log in or register to reply here.
Back
Top