Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 294198 - Strigi fails to initialize; needs /usr/lib/libjvm.so
Summary: Strigi fails to initialize; needs /usr/lib/libjvm.so
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo KDE team
URL: http://aldeby.org/blog/index.php/nepo...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-23 14:58 UTC by Christoph Lange
Modified: 2010-10-01 22:36 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Output from ldd (ldd_output,928 bytes, text/plain)
2009-12-02 10:01 UTC, Stephan Schenk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Lange 2009-11-23 14:58:17 UTC
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
Comment 1 Tomáš Chvátal (RETIRED) gentoo-dev 2009-11-24 22:02:21 UTC
Guys anything we in kde are doing wrong, or anything that can be fixed on your side.
Comment 2 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2009-11-24 22:38:14 UTC
Anything in revdep-rebuild? Did one of those packages set rpath to a JDK location that changed after upgrade or something?
Comment 3 Christoph Lange 2009-11-25 00:29:21 UTC
(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.
Comment 4 Alistair Bush (RETIRED) gentoo-dev 2009-11-29 04:54:35 UTC
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 ;)
Comment 5 Stephan Schenk 2009-12-02 10:01:47 UTC
Created attachment 211741 [details]
Output from ldd
Comment 6 Stephan Schenk 2009-12-02 10:28:35 UTC
(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.
Comment 7 Andreas K. Hüttel gentoo-dev 2010-07-07 18:26:43 UTC
Is this still a problem with strigi-0.7.2 ?
Comment 8 Andreas K. Hüttel gentoo-dev 2010-10-01 22:36:04 UTC
No response for three months, so I'll assume this is fixed in more recent versions. 

Please reopen if the problem reoccurs.