soprano-backend-sesame requires missing /usr/lib/libjvm.so

With the Jaunty/9.04, soprano-backend-sesame_2.2.1-0ubuntu1. i386

ldd /usr/lib/soprano/libsoprano_sesame2backend.so is telling: libjvm.so => not found

but locate locate libjvm.so is telling:

/usr/lib/gcj-4.3-90/libjvm.so
/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/lib/i386/server/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/cacao/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so
/usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/i386/client/libjvm.so
/usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/i386/server/libjvm.so

I added symlink:
sudo ln -s /usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so
and it did the trick.

Whole story: http://kubuntuforums.net/forums/index.php?topic=3102231.0

So is this a java packaging bug or still a sesame bug?

Thanks for your link Sam Rog.
Since I have a 64Bit-system I had to use a different linklocation to get it working.
ln -s /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/amd64/server/libjvm.so /usr/lib/libjvm.so

PS: Maybe some other 64bit users should conform this workaround... :-D

sudo ln -s /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server/libjvm.so /usr/lib/libjvm.so
or
sudo ln -s /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/amd64/server/libjvm.so /usr/lib/libjvm.so

works fine in my system (jaunty 64bit)

For me, on jaunty 64bit, it was
sudo ln -s /usr/lib/jvm/java-6-sun/jre/lib/amd64/server/libjvm.so /usr/lib/libjvm.so
 (with java-6-sun instead of java-6-sun-1.6.0.12)

Why is that needed? Is there anything wrong with adding that link manually?

Instead of adding a symlink I created a file called /etc/ld.so.conf.d/java.conf which contained :

/usr/lib/jvm/java-6-sun-1.6.0.13/jre/lib/amd64/server/

That was enough to get the library resolved.

Should it be the Java packages fixing this ? I would have thought that they would be using the alternatives system to specify this library if it's required by external applications.

As all the others I can also confirm this bug.

I've cross-filed this against java-common as it might be update-java-alternatives' responsibility to symlink libjvm.so.

Confirmed here as well.

It's worth mentioning that you probably have to run ldconfig after adding the /etc/ld.so.conf.d/java.conf file to use it right away.

Just chiming in to confirm this bug. I did (roughly) what Chris Samuel described and Strigi / Nepomuk took right off. Since KDE4 has a reasonable focus and integration with the semantic desktop, it seems prudent to get this fix in ASAP.

It seems like it would be a Java packaging bug, as it's probably the responsibility of the Java package to register its runtime library with ld.so.

I've just noticed I had the path to a particular instance of Java in my file, it should have really been:

 /usr/lib/jvm/java-6-sun/jre/lib/amd64/server/

as /usr/lib/jvm/java-6-sun is a symlink to the current version of Java and hence won't break Soprano when an updated version of Java is installed.

In reply to #9, shouldn't the sesame2 package be responsible for installing the appropriate file in /etc/ld.so.conf.d/, instead of the java package doing it?

Will there be a fix in the near future? The problem is known for months now and apparently nothing happened. A solution doesn't look *that* complicated ... ;)

In my thoughts this is a problem, which shall be decided by the JVM packagers. libjvm.so is also in the gcj package.

Somehow either
- the way sesame accesses libjvm.so shall change, e.g. by loading on-demand. Building it by hand using cmake and the source package; the lib automatically gets the path to libjvm.so inserted (by using the ld rpath option). so it seems like libjvm.so lies at /usr/lib (or somewhere in the path) on the build machine already.
- sun jvm / gcc jvm shall publish their lib-path to /etc/ld.so.conf

If the sesame-plugin would add /etc/ld.so.conf/ path for itself; this would just be a dirty workaround.

Please say we'll get this into Karmic...

still not fixed in Kubuntu Karmic Koala (3K)
have to add

sudo ln -s /usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so

or with sun-java

sudo ln -s /usr/lib/jvm/java-6-sun/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so

:(

Note re the paths above, if you have a 64 bit version of (K)Ubuntu, you need to replace i386 with amd64 for this to work. That is all. :)

Am I the only one here who finds it ironic that the status on this in Java is "New" when this problem has been around since at least Feisty? (That is, Feisty which came out two and a half years ago...)

As an uneducated layperson, it seems that you always have java where you have soprano, but you don't always have soprano where you have java, ergo this could be fixed by having an install script with soprano that found the latest version of java and linked to it. The java package could also have something that called that same script (if soprano is installed) to update the linkage for each new java version.

Now if only I knew how to code! ;)

It would be silly if it wasn't solved for Karmic...

Resolution is clear: create /etc/alternatives for /usr/lib/libjvm.so. Java JRE's are the only packages that could know the right path of that library. KDE uses the path hardcoded when it's compiled, so if it found it every time in /usr/lib it would be very nice.

It is not hard, it is not complicated, it's just to add one alternative to many ones now existing... If /usr/lib location is not what you want, it can be anywhere, until KDE can find it when building.

The sesame backend is gone for 10.04, as the KDE developers dropped support for it. It was replaced by the Virtuoso backend.