lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: using org.apache.jcc.PythonVM
Date Sat, 05 Mar 2011 03:22:49 GMT

On Fri, 4 Mar 2011, Bill Janssen wrote:

> Andi Vajda <> wrote:
>> Something's off. is not shown in your list.
>> You need to solve that mystery before embedding can proceed.
> So, I went to my Mac, and looked for libjcc.dylib.  Sure enough,
> it's there.  So I tried this simple program:
> import org.apache.jcc.PythonVM;
> public class test {
>    public static void main (String[] argv) {
>        PythonVM.start("/usr/bin/python",
>             new String[] { "-c", "import time; print time.localtime()"});
>    }
> }

It seems that you think that this is going to run /usr/bin/python.
Not really. The dynamic linker is going to load whatever libpython.dylib JCC 
was linked with, provided it knows to do that (see below), then JCC is 
going to call
    Py_SetProgramName("/usr/bin/python") and
    PySys_SetArgv({"/usr/bin/python", "-c", "import time; print time.localtime()")
This is done in jcc.cpp, in the _PythonVM_init() function.

No python code is going to be executed until you actually call instantiate() 
with a python module and class name. These argv things are just stuffed into 
sys.argv, not interpreted or anything.

> Here's what happens:

See below...

> % javac -classpath /Library/Python/2.5/site-packages/JCC-2.6-py2.5-macosx-10.5-i386.egg/jcc/classes:.
> % java -Djava.library.path=/Library/Python/2.5/site-packages/JCC-2.6-py2.5-macosx-10.5-i386.egg
-classpath /Library/Python/2.5/site-packages/JCC-2.6-py2.5-macosx-10.5-i386.egg/jcc/classes:.
> Exception in thread "main" java.lang.UnsatisfiedLinkError: /Library/Python/2.5/site-packages/JCC-2.6-py2.5-macosx-10.5-i386.egg/libjcc.dylib:
 Symbol not found: __Py_NoneStruct   Referenced from: /Library/Python/2.5/site-packages/JCC-2.6-py2.5-macosx-10.5-i386.egg/libjcc.dylib
  Expected in: dynamic lookup
> 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> 	at java.lang.ClassLoader.loadLibrary0(
> 	at java.lang.ClassLoader.loadLibrary(
> 	at java.lang.Runtime.loadLibrary0(
> 	at java.lang.System.loadLibrary(
> 	at org.apache.jcc.PythonVM.<clinit>(
> 	at test.main(
> % otool -L /Library/Python/2.5/site-packages/JCC-2.6-py2.5-macosx-10.5-i386.egg/libjcc.dylib
> /Library/Python/2.5/site-packages/JCC-2.6-py2.5-macosx-10.5-i386.egg/libjcc.dylib:
> 	@rpath/libjcc.dylib (compatibility version 2.6.0, current version 2.6.0)
> 	/System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM (compatibility version
1.0.0, current version 1.0.0)
> 	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.5)

Notice how libpython.dylib (or whatever its correct name is) is not listed 
here. This means that JCC was built to expect the main process to provide 
libpython.dylib to the dynamic linker which works in the usual - starting in 
a python process - case.

To fix that, to help the dynamic linker to load that library, you need to 
change the LFLAGS for 'darwin' in JCC's to also list the python 
framework by adding '-framework', 'Python' to that list.
After rebuilding JCC, be sure then that otool lists libpython.dylib to 
verify that it worked.


View raw message