The URL given above describes the problem on Ubuntu, but on Gentoo I had the same problem, and the same fix helped. Reproducible: Always Steps to Reproduce: see URL Installed packages: kde-base/nepomuk-4.3.3 using debug handbook app-misc/strigi-0.7.0 using clucene dbus exif fam hyperestraier inotify qt4
Guys anything we in kde are doing wrong, or anything that can be fixed on your side.
Anything in revdep-rebuild? Did one of those packages set rpath to a JDK location that changed after upgrade or something?
(In reply to comment #2) > Anything in revdep-rebuild? Did one of those packages set rpath to a JDK > location that changed after upgrade or something? Not sure it that information helps you, but I did revdep-rebuild (actually reconcilio of paludis) before.
Mmmm... probably wont help seeing you ran reconcillo but ldd /usr/lib64/soprano/libsoprano_sesame2backend.so also try reinstalling soprano?(In reply to comment #1) > Guys anything we in kde are doing wrong, or anything that can be fixed on your > side. > Oh were should we begin ;)
Created attachment 211741 [details] Output from ldd
(In reply to comment #5) > Created an attachment (id=211741) [details] > Output from ldd As the ldd output shows (see attachment), libjvm.so is found on my system. HOWEVER, this only works if and only if soprano was rebuilt _AFTER_ any eselect java-vm. I'am not an expert at this but from a readelf --dynamic /usr/lib/soprano/libsoprano_sesame2backend.so one sees that the library has an R{,UN}PATH set to the directory containing the libjvm from my java-vm: Library rpath: [/usr/lib64:/opt/sun-jdk-1.6.0.17/jre/lib/amd64/server:/usr/lib64/qt4]). If I run the same command on another machine where soprano was built with another java-vm (sun-jdk-1.6.0.16) installed, then the path to this VM shows up although the 1.6.0.16 version has long been replaced by the .17 one. To me the situation looks like the following: soprano detects the path to libjvm.so at build time and hard-codes it via RPATH into the binary. Whenever the VM changes, this hard-coded path is no longer valid. An obvious solution to me would be to drop a file into /etc/env.d/ containing an appropriate LDPATH. This file, of course, must be handled by the java-vm eselect module. Although this might fix the libjvm issue in a general way I do not foresee any unwanted side effects. I guess the java herd can help out with this.
Is this still a problem with strigi-0.7.2 ?
No response for three months, so I'll assume this is fixed in more recent versions. Please reopen if the problem reoccurs.