Hi, Andreas. Last question, first: when I hit the reply
button, your email address shows up as [email protected].
I don't have a libpython2.6.so.1.0 in my
/usr/common/usg/python/2.6.4/lib directory, only libpython2.6.a
I ran the vanilla configure/build sequence:
./configure --prefix=/usr/common/usg/python/2.6.4
make
make install
so I guess I need to set --ehable-shared to get the *.so file?
I ran objdump on the *system* version of libboost_python, and
it is
% objdump -T /usr/lib64/libboost_python.so.2 | grep UCS
0000000000000000 D *UND* 0000000000000000
PyUnicodeUCS4_FromEncodedObject
0000000000000000 D *UND* 0000000000000000
PyUnicodeUCS4_AsWideChar
The I ran objdump on the version that I built, and it is
a% objdump -T
/usr/common/usg/boost/1_40_0/pool/lib/libboost_python.so.1.40.0 | grep UCS
0000000000000000 D *UND* 0000000000000000
PyUnicodeUCS4_FromEncodedObject
0000000000000000 D *UND* 0000000000000000
PyUnicodeUCS4_AsWideChar
so they are both UCS4.
The system version of libpython2.4.so also is UCS4.
In pyconfig.h in the version of Python 2.6.4 that I built
Py_UNICODE_SIZE is defined as 2, whereas in the
system version (Python 2.4), it is defined to be 4.
I take this to mean that I need to rebuild python and
specify --enable-unicode=ucs4 and --enable-shared
when I run the configure step. Are there other
configure options that I should include?
Thanks for all of your help,
Janet
Andreas Klöckner wrote:
On Freitag 20 November 2009, Janet Jacobsen wrote:
Hi, Andreas. I ran
ldd /usr/common/usg/python/2.6.4/lib/python2.6/site-packages
/pycuda-0.93.1rc2-py2.6-linux-x86_64.egg/pycuda/_driver.so
and got
libboost_python.so.1.40.0 =>
/usr/common/usg/boost/1_40_0/pool/lib/libboost_python.so.1.40.0
(0x00002b259cac6000)
libboost_thread.so.1.40.0 =>
/usr/common/usg/boost/1_40_0/pool/lib/libboost_thread.so.1.40.0
(0x00002b259cd15000)
libcuda.so.1 => /usr/lib64/libcuda.so.1 (0x00002b259cf43000)
libstdc++.so.6 => /usr/common/usg/gcc/4.4.2/lib64/libstdc++.so.6
(0x00002b259d3df000)
libm.so.6 => /lib64/libm.so.6 (0x00002b259d6eb000)
libgcc_s.so.1 => /usr/common/usg/gcc/4.4.2/lib64/libgcc_s.so.1
(0x00002b259d96e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b259db85000)
libc.so.6 => /lib64/libc.so.6 (0x00002b259dda0000)
libutil.so.1 => /lib64/libutil.so.1 (0x00002b259e0f6000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b259e2fa000)
librt.so.1 => /lib64/librt.so.1 (0x00002b259e4fe000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00002b259e707000)
/lib64/ld-linux-x86-64.so.2 (0x000000316ec00000)
Does this help?
Hmm, yes and no. I'm starting to believe that Boost built itself thinking that
you have an UCS4 Python, while your actual build is UCS2. To confirm that
latter point, run the equivalent of
objdump -T /users/kloeckner/mach/x86_64/pool/lib/libpython2.6.so.1.0|grep UCS
That should tell you what the UCS'iness of your custom Python is. Then run
objdump -T /usr/common/usg/boost/1_40_0/pool/lib/libboost_python.so.1.40.0 |
grep UCS
to establish Boost's UCS'iness. As I said, I'm suspecting that the two might
disagree. You might want to try that against your system Python 2.4, too.
Maybe Boost cleverly found that one and picked it up. In any case, the switch
to look for is "Py_UNICODE_SIZE" in pyconfig.h.
P.S. Sorry if this should be off-list, but email sent to
[email protected] is returned to me.
On-list is the right place IMO--this creates a searchable record of problems
and solutions. Thanks for asking though. (Btw: where'd you get that email
address? While tiker.net is my domain, I don't recall using or having created
that address.)
HTH,
Andreas
_______________________________________________
PyCUDA mailing list
[email protected]
http://tiker.net/mailman/listinfo/pycuda_tiker.net
