/Developer/SDKs/MacOSX10.6.sdk/usr/local/lib is just a symlink link
to /usr/local/lib.
won't fix the prob
thanks.

Ah, didn't realize that was a symlink.
DYLD_LIBRARY_PATH is definitely set on the shell you're running
"python test_wrapper.py" from?
You could check if that symbol it's looking for is exported by the
boost in /usr/local/lib/libboost_python.dylib:
dyldinfo -export /usr/local/lib/libboost_python.dylib | grep
__ZNK5boost6python7objects21py_function_impl_base9max_arityEv
-jsnyder

On Sep 15, 2009, at 4:04 PM, James Snyder wrote:
>
> On Sep 15, 2009, at 1:55 PM, Andreas Klöckner wrote:
>
>> Hi Jassin,
>>
>> a) please don't email me directly. Instead, please use the mailing
>> list.
>>
>> b) It looks like you have a boost version mismatch, i.e. the
>> headers for the
>> boost library which you are using for the compilation don't match
>> the library
>> that gets found at run time. Check for multiple installations of
>> Boost.
>
> I concur, it looks as if you might have a version of boost being
> found at link time and one being found later when dynamic lookup
> takes place.
>
> If I had to guess, based on the compiler messages and the later
> message, you're linking against an install of boost that went into
> your 10.6 SDK directory (not sure why), and later it is using the
> one from /usr/local/lib.
>
> You could check if the dynamic lookups work if you include /
> Developer/SDKs/MacOSX10.6.sdk/usr/local/lib in your
> DYLD_LIBRARY_PATH. I'm not sure if that's a good idea in the long
> run though. I might remove the boost libraries & headers from the
> SDK dir, make sure you have the correct version in /usr/local/lib
> or wherever you wish to have them installed, and then try
> rebuilding things.
>
>>
>> HTH,
>> Andreas
>>
>> On Dienstag 15 September 2009, you wrote:
>>> hi i tried to install opencl under macosx 10.6.1 unfortunnatly when
>>> starting the example i get :
>>>
>>> python test_wrapper.py
>>> Traceback (most recent call last):
>>> File "test_wrapper.py", line 205, in <module>
>>> import pyopencl
>>> File
>>> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
>>> site-pack
>>> ages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/
>>> __init__.py", line 3,
>>> in <module> import pyopencl._cl as _cl
>>> ImportError:
>>> dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/
>>> python2.6/sit
>>> e-packages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/
>>> _cl.so, 2):
>>> Symbol not found:
>>> __ZNK5boost6python7objects21py_function_impl_base9max_arityEv
>>> Referenced
>>> from:
>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
>>> site-packa
>>> ges/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so
>>> Expected in:
>>> dynamic lookup
>>>
>>>
>>>
>>> during make i get :
>>>
>>> ld: warning: in
>>> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
>>> libboost_python.dylib, file
>>> is not of required architecture ld: warning: in
>>> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
>>> libboost_thread.dylib, file
>>> is not of required architecture
>>>
>>>
>>> what is /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib ?
>
> That architecture complaint may be OK. I think this may just be
> because boost is built for x86_64 and the other libraries (OpenCL,
> Python, etc..) are fat binaries with i386 and x86_64. I get the
> complaint that the libboost_* libraries I'm using aren't of the
> required architecture.
>
> I'm not sure why they're installed in that location though. My
> 10.6 SDK doesn't have boost libraries there.
>
>>>
>>> my specs are :
>>>
>>> gcc version 4.2.1 (Apple Inc. build 5646)
>>> boost 1.40 /usr/local/include and /usr/local/lib
>
> Looks like you've got a version installed in /Developer/SDKs/
> MacOSX10.6.sdk/usr/local/lib as well?
>
>>> Python 2.6.2
>>> Numpy 1.3.0
>>>
>>> did the same way you described under the wiki
>>>
>>> python configure.py --boost-inc-dir=/usr/local/include
>>> --boost-lib-dir=/usr/local/lib --boost-python-
>>> libname=boost_python
>>> --boost-thread-libname=boost_thread --cl-libname=''
>>> --ldflags='-Wl,-framework,OpenCL' --boost-compiler='gcc42'
>>>
>>> echo $DYLD_LIBRARY_PATH : /usr/local/lib:/usr/local/cuda/lib
>>>
>>> Any idea?
>>>
>>>
>>> thank you very much in advance. I m very exited about the
>>> pyOpencl project
>>>
>>
>> _______________________________________________
>> PyOpenCL mailing list
>> PyOpenCL(a)tiker.net
>> http://tiker.net/mailman/listinfo/pyopencl_tiker.net
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder(a)fanplastic.org
> http://fanplastic.org/key.txt
> ph: 847.448.0386
>
>
>
>

dyldinfo returns
0x00014E90 __ZNK5boost6python7objects21py_function_impl_base9max_arityEv
so the missing reference is exported by the lib.
Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-
packages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so
path has a subfolder pyopencl-0.91-py2.6-macosx-10.3-fat.egg. Macosx
10.3 ? I used the latest pyopencl build 0.91
On Sep 15, 2009, at 5:13 PM, James Snyder wrote:

On Sep 15, 2009, at 3:14 PM, Jassin MEKNASSI wrote:
> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib is just a symlink link
> to /usr/local/lib.
> won't fix the prob
> thanks.
Ah, didn't realize that was a symlink.
DYLD_LIBRARY_PATH is definitely set on the shell you're running
"python test_wrapper.py" from?
You could check if that symbol it's looking for is exported by the
boost in /usr/local/lib/libboost_python.dylib:
dyldinfo -export /usr/local/lib/libboost_python.dylib | grep
__ZNK5boost6python7objects21py_function_impl_base9max_arityEv
-jsnyder
>
> On Sep 15, 2009, at 4:04 PM, James Snyder wrote:
>
>>
>> On Sep 15, 2009, at 1:55 PM, Andreas Klöckner wrote:
>>
>>> Hi Jassin,
>>>
>>> a) please don't email me directly. Instead, please use the
>>> mailing list.
>>>
>>> b) It looks like you have a boost version mismatch, i.e. the
>>> headers for the
>>> boost library which you are using for the compilation don't match
>>> the library
>>> that gets found at run time. Check for multiple installations of
>>> Boost.
>>
>> I concur, it looks as if you might have a version of boost being
>> found at link time and one being found later when dynamic lookup
>> takes place.
>>
>> If I had to guess, based on the compiler messages and the later
>> message, you're linking against an install of boost that went into
>> your 10.6 SDK directory (not sure why), and later it is using the
>> one from /usr/local/lib.
>>
>> You could check if the dynamic lookups work if you include /
>> Developer/SDKs/MacOSX10.6.sdk/usr/local/lib in your
>> DYLD_LIBRARY_PATH. I'm not sure if that's a good idea in the long
>> run though. I might remove the boost libraries & headers from the
>> SDK dir, make sure you have the correct version in /usr/local/lib
>> or wherever you wish to have them installed, and then try
>> rebuilding things.
>>
>>>
>>> HTH,
>>> Andreas
>>>
>>> On Dienstag 15 September 2009, you wrote:
>>>> hi i tried to install opencl under macosx 10.6.1 unfortunnatly
>>>> when
>>>> starting the example i get :
>>>>
>>>> python test_wrapper.py
>>>> Traceback (most recent call last):
>>>> File "test_wrapper.py", line 205, in <module>
>>>> import pyopencl
>>>> File
>>>> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
>>>> site-pack
>>>> ages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/
>>>> __init__.py", line 3,
>>>> in <module> import pyopencl._cl as _cl
>>>> ImportError:
>>>> dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/
>>>> python2.6/sit
>>>> e-packages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/
>>>> _cl.so, 2):
>>>> Symbol not found:
>>>> __ZNK5boost6python7objects21py_function_impl_base9max_arityEv
>>>> Referenced
>>>> from:
>>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
>>>> site-packa
>>>> ges/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so
>>>> Expected in:
>>>> dynamic lookup
>>>>
>>>>
>>>>
>>>> during make i get :
>>>>
>>>> ld: warning: in
>>>> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
>>>> libboost_python.dylib, file
>>>> is not of required architecture ld: warning: in
>>>> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
>>>> libboost_thread.dylib, file
>>>> is not of required architecture
>>>>
>>>>
>>>> what is /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib ?
>>
>> That architecture complaint may be OK. I think this may just be
>> because boost is built for x86_64 and the other libraries (OpenCL,
>> Python, etc..) are fat binaries with i386 and x86_64. I get the
>> complaint that the libboost_* libraries I'm using aren't of the
>> required architecture.
>>
>> I'm not sure why they're installed in that location though. My
>> 10.6 SDK doesn't have boost libraries there.
>>
>>>>
>>>> my specs are :
>>>>
>>>> gcc version 4.2.1 (Apple Inc. build 5646)
>>>> boost 1.40 /usr/local/include and /usr/local/lib
>>
>> Looks like you've got a version installed in /Developer/SDKs/
>> MacOSX10.6.sdk/usr/local/lib as well?
>>
>>>> Python 2.6.2
>>>> Numpy 1.3.0
>>>>
>>>> did the same way you described under the wiki
>>>>
>>>> python configure.py --boost-inc-dir=/usr/local/include
>>>> --boost-lib-dir=/usr/local/lib --boost-python-
>>>> libname=boost_python
>>>> --boost-thread-libname=boost_thread --cl-libname=''
>>>> --ldflags='-Wl,-framework,OpenCL'
--boost-compiler='gcc42'
>>>>
>>>> echo $DYLD_LIBRARY_PATH : /usr/local/lib:/usr/local/cuda/lib
>>>>
>>>> Any idea?
>>>>
>>>>
>>>> thank you very much in advance. I m very exited about the
>>>> pyOpencl project
>>>>
>>>
>>> _______________________________________________
>>> PyOpenCL mailing list
>>> PyOpenCL(a)tiker.net
>>> http://tiker.net/mailman/listinfo/pyopencl_tiker.net
>>
>> --
>> James Snyder
>> Biomedical Engineering
>> Northwestern University
>> jbsnyder(a)fanplastic.org
>> http://fanplastic.org/key.txt
>> ph: 847.448.0386
>>
>>
>>
>>
>
--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder(a)fanplastic.org
http://fanplastic.org/key.txt
ph: 847.448.0386

dyldinfo returns
0x00014E90
__ZNK5boost6python7objects21py_function_impl_base9max_arityEv
so the missing reference is exported by the lib.
Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-
packages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so
path has a subfolder pyopencl-0.91-py2.6-macosx-10.3-fat.egg. Macosx
10.3 ? I used the latest pyopencl build 0.91

The 10.3 is likely because you're using python2.6 that you installed
separately from Apple's, if you run python do you get version info
like the following:
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Apple's Python resides in: /System/Library/Frameworks/Python.framework/
Versions/2.6/ rather than /Library/Frameworks/Python.framework/
Versions/2.6/
The one other possibility that occurs to me... check which
architectures your python is built for:
lipo -info `which python`
I get:
Architectures in the fat file: /usr/bin/python are: x86_64 i386 ppc7400
Check if your boost library matches up:
lipo -info /usr/local/lib/libboost_python.dylib
Mine built for a single architecture, x86_64, which is fine with
Apple's Python (starts in x86_64 mode). It could be that boost found
the Apple Python (or not?) and only built 64-bit binaries. There
would, however, be a problem if boost is 64-bit and 32-bit python is
trying to load it.
It looks like to make fat binaries from boost correctly would require
something like this:
./bjam -j4 variant=release link=shared architecture=x86 address-
model=32_64 install
However, it sounds like the build system doesn't behave correctly on
snow leopard without some nudging:
http://article.gmane.org/gmane.comp.lib.boost.user/51249
I used the adjustment for gcc.jam described about half-way down.
Change should look something like this:
tools/build/v2/tools/gcc.jam:377
- option = -m64 ;
+ if $(model) = 32_64
+ {
+ }
+ else
+ {
+ option = -m64 ;
+ }
I haven't finished building it yet, so I'm not sure if that fix
definitely yields the expected architectures.

Works: boost built as a fat binary (x86_64 & i386), using Apple's
Python forced to 32-bit mode, and Apple's NumPy 1.2 (which is a fat
binary). Running 64-bit also works.
Strangely NumPy 1.4dev seems to have problems when built 32/64 and run
as 32 at least for certain circumstances:
http://projects.scipy.org/numpy/ticket/1221
That issue is totally unrelated to PyOpenCL, but I've mentioned it
here in case anyone else runs into trouble with running a 32/64-bit
binary in 32-bit mode.
-jsnyder
On Sep 15, 2009, at 5:38 PM, James Snyder wrote: