| Summary: | Strigi fails to initialize; needs /usr/lib/libjvm.so | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christoph Lange <langec> |
| Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | java, kamensky.fb, mail |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://aldeby.org/blog/index.php/nepomuck-and-stringi-kubuntu-910-strigi-service-failed-to-initialize.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Output from ldd | ||
|
Description
Christoph Lange
2009-11-23 14:58:17 UTC
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. |
