PyLucene: How to package libraries that link against OpenJDK libraries?

Felix Schwarz felix.schwarz at oss.schwarz.eu
Mon Jun 2 13:35:00 UTC 2008


Andrew Haley schrieb:
> Felix Schwarz wrote:
> 
>> So I think JCC is basically the right thing to do as this is the only
>> way you can always use the latest Python features (even Python packages
>> that are written in C) and the latest Java (GCJ always had threading
>> issues and is generally hard to debug).
> 
> I'm not going to let this one past.  gcj does not have "threading issues",
> whatever that means, and I don't agree that it's hard to debug.  The latter
> is a matter of opinion, but the former a matter of fact.

You are correct that threading inside of gcj was seemingly not that bad. I
should be more precise in my wording because these "threading issues" were
related to Python's threading - with a gcj compiled Lucene you had to be quite
careful what Python threading implementation you use (something that caused
some problems with CherryPy/TurboGears).

>>> Specifically, "If the JNI-using code calls System.loadLibrary you'll
>>> have to patch it to use System.load, passing it the full path to the
>>> dynamic shared object."
>>>
>>> For an example of this see
>>> http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/
>> Sorry, my wording was not detailed enough. JCC does "JNI the other way
>> round" so it calls Java from C++. Therefore there is no
>> System.loadLibrary which could be patched. Instead I have to rely on the
>> standard linker configuration (or use rpath).
> 
> Or use a full path in dlopen().

I may be wrong but it seems that JCC does do any dlopens. Instead the code
is just linked against the Java libraries. I may be wrong on this, though.

> What libraries does JCC need to open?  Just libjvm, or others?

libjava.so and libjvm.so.

fs




More information about the fedora-devel-list mailing list