FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-22-2008, 09:33 PM
Felix Schwarz
 
Default PyLucene: How to package libraries that link against OpenJDK libraries?

Hi,

I'm trying to package JCC/PyLucene. Now that OpenJDK made it into Fedora (and
EPEL 5), PyLucene with JCC could possibly be included with Fedora.


But I'm facing some problems writing the spec files, therefore I did not
submit the packages for a review:

- JCC rpm [1]: include and lflags are set in setup.py which I have to change
so that the file contains the rights paths. How can I get these paths while
avoid these pitfalls:
a) Do not have to rebuild JCC every time OpenJDK gets a version bump?
b) Use the correct arch? (...lib/i386) - ok that one could be solved with
some shell scripting in the spec file
c) How to get the correct vm type? On i386 there is a client and a server
vm. Is there a way I can "just" get the client vm directory (and as a
fallback the server vm)?
d) JCC uses JNI so the library paths must be set correctly at runtime.
Unfortunately, the OpenJDK package does not add its paths to
/etc/ld.so.conf.d (did I miss something?) Is there another workaround
besides using rpath (bad, see a) or filing a bug against OpenJDK?

- PyLucene rpm [2]: Besides the linker search path I have another problem with
the version number. PyLucene uses version numbers which are illegal in RPM
such as "2.3.2-1" (sic!). I think the best way to handle it (besides
upstream changing the numbering schema) is just to use "2.3.2.1". Any
objections?

And last but not least the naming: PyLucene seems pretty clear to me, it
conforms to the Python packaging guidelines. But what to do with JCC? It is
essentially a python application containing a C++ library which links against
the JDK. Should this be called python-jcc?


Probably many of these questions are very much newbie-style and may be trivial
for the more experienced but all pointers are appreciated :-)


fs

[1] http://www.schwarz.eu/opensource/rpm/JCC/1.9-2/
[2] http://www.schwarz.eu/opensource/rpm/PyLucene/2.3.2-1/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 10:09 PM
"Colin Walters"
 
Default PyLucene: How to package libraries that link against OpenJDK libraries?

On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz
<felix.schwarz@oss.schwarz.eu> wrote:
> Hi,
>
> I'm trying to package JCC/PyLucene. Now that OpenJDK made it into Fedora
> (and EPEL 5), PyLucene with JCC could possibly be included with Fedora.

Wow, JCC is terrifying. Interacting with Lucene via Jython would be...saner =)

> But I'm facing some problems writing the spec files, therefore I did not
> submit the packages for a review:
> - JCC rpm [1]: include and lflags are set in setup.py which I have to change
> so that the file contains the rights paths. How can I get these paths while
> avoid these pitfalls:

Fix the upstream setup.py to detect JPackage compatible VM layouts.
Basically the directory /usr/lib/jvm/java has the current default VM.

The algorithm I used in a patch for java-gnome is to check whether
/etc/java/jpackage-release exists, and if so assume a JPackage
compatible layout. You could also just look in /usr/lib/jvm/java too.

> a) Do not have to rebuild JCC every time OpenJDK gets a version bump?

I don't think so, but that's a question for JCC upstream.

> b) Use the correct arch? (...lib/i386) - ok that one could be solved with
> some shell scripting in the spec file

Fix the upstream setup.py

> c) How to get the correct vm type? On i386 there is a client and a server
> vm. Is there a way I can "just" get the client vm directory (and as a
> fallback the server vm)?

Hm, if the project needs to poke at the internal VM libraries I'm not
sure there's a clean way to do that, but an OpenJDK hacker might be
able to give you an answer.

> d) JCC uses JNI so the library paths must be set correctly at runtime.
> Unfortunately, the OpenJDK package does not add its paths to
> /etc/ld.so.conf.d (did I miss something?) Is there another workaround
> besides using rpath (bad, see a) or filing a bug against OpenJDK?

Right now, you should hardcode the paths to the library in your package. See:
http://fedoraproject.org/wiki/Packaging/Java#head-61a3ee0d05ff616ef9be2021b489610e036fd932
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/

This is necessary until we get multilib-awareness into OpenJDK upstream.

> - PyLucene rpm [2]: Besides the linker search path I have another problem
> with
> the version number. PyLucene uses version numbers which are illegal in RPM
> such as "2.3.2-1" (sic!). I think the best way to handle it (besides
> upstream changing the numbering schema) is just to use "2.3.2.1". Any
> objections?

Sounds reasonable.

> And last but not least the naming: PyLucene seems pretty clear to me, it
> conforms to the Python packaging guidelines. But what to do with JCC? It is
> essentially a python application containing a C++ library which links
> against the JDK. Should this be called python-jcc?

Sure.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-23-2008, 12:19 PM
"Colin Walters"
 
Default PyLucene: How to package libraries that link against OpenJDK libraries?

On Fri, May 23, 2008 at 5:13 AM, Andrew Haley <aph@redhat.com> wrote:
>
> Interesting. What multilib-awareness do you think we need? It's not
> immediately clear to me where the beinefit would be.

Code calling System.loadLibrary (i.e. most software out there that
wants to dlopen) would work.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-23-2008, 01:09 PM
"Colin Walters"
 
Default PyLucene: How to package libraries that link against OpenJDK libraries?

On Fri, May 23, 2008 at 8:58 AM, Andrew Haley <aph@redhat.com> wrote:
> Colin Walters wrote:
>> On Fri, May 23, 2008 at 5:13 AM, Andrew Haley <aph@redhat.com> wrote:
>>> Interesting. What multilib-awareness do you think we need? It's not
>>> immediately clear to me where the beinefit would be.
>>
>> Code calling System.loadLibrary (i.e. most software out there that
>> wants to dlopen) would work.
>
> Well yes, obviously, but in what way would multilib-awareness help?
> Even if you have a mixture of 32-bit and 64-bit VMs in the same system,
> the VMs themselves wouldn't need to be multilib-aware.

I didn't write that section of the Java guidelines, so perhaps I'm
misinterpreting it. But I read "...modifying IcedTea to look for JNI
shared objects in %{_libdir}/jni" as "multilib-aware". But maybe the
operative change is the /jni and not the %{libdir}, so the
IcedTea/OpenJDK change is really to be "JPackage layout aware"?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-23-2008, 04:54 PM
Caolan McNamara
 
Default PyLucene: How to package libraries that link against OpenJDK libraries?

On Fri, 2008-05-23 at 10:13 +0100, Andrew Haley wrote:
> Colin Walters wrote:
> > On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz
> > <felix.schwarz@oss.schwarz.eu> wrote:
> >
> >> c) How to get the correct vm type? On i386 there is a client and a server
> >> vm. Is there a way I can "just" get the client vm directory (and as a
> >> fallback the server vm)?
> >
> This is a bit mysterious. I guess I don't understand why PyLucene
> would want to poke at the internal VM libraries.

*Possibly* so as to be able to dlopen libjvm.so in order to call
JNI_CreateJavaVM

C.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-02-2008, 07:11 PM
"Colin Walters"
 
Default PyLucene: How to package libraries that link against OpenJDK libraries?

On Mon, Jun 2, 2008 at 8:26 AM, Felix Schwarz <felix.schwarz@oss.schwarz.eu> wrote:



In my understanding Jython better suited/the best possibility if I want to call Python from Java code. If the main program is in Python, using Jython will restrict you on a Python feature set that is roughly the same as in Python 2.2.

Jython in SVN is 2.3 + some 2.4 features, and some 2.5 libraries.* Here's a slightly old status report:
http://groups.google.com/group/jvm-languages/browse_thread/thread/e53015c684f69d2d


Hopefully they'll do a new release sometime soon.


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).

There are different tradeoffs; wedging two completely separate runtimes into the same process gives you a lot of integration issues - garbage collectors that aren't aware of each other, etc.**



Furthermore using JCC you can even use Java from C++ without too much hassle - quite cool I think :-)

Yeah; it does make sense I think to ship JCC.* But once Jython is able to run major web frameworks like Django/TurboGears, there will be less need for it.

*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).

Ah, I see. I think it makes the most sense to either put libjvm.so in $libdir or use dlopen, but that's more of a detail for the OpenJDK/Icedtea hackers.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 09:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org