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