Bulding Boost.Python on OSX
Forgive me, but it doesn't look like the specific Boost.Python list is active so I'm posting this here. I followed the relevant directions and built Boost.Python on my Mac using bjam, which gave the following output: ...patience... ...patience... ...found 1356 targets... ...updating 54 targets... <snip> ...failed updating 1 target... ...skipped 6 targets... ...updated 47 targets... I now see embedding.o and extending.o in the bin/gcc-4.01/debug directory within the quickstart directory. But when I run test_extending.py, the script fails and gives "ImportError: No module named extending". How do I get the python script to import the extending module? Thank you for your time.
AMDG Z. S. O. wrote:
Forgive me, but it doesn't look like the specific Boost.Python list is active so I'm posting this here. I followed the relevant directions and built Boost.Python on my Mac using bjam, which gave the following output:
...patience... ...patience... ...found 1356 targets... ...updating 54 targets... <snip> ...failed updating 1 target... ...skipped 6 targets... ...updated 47 targets...
Something failed to build. Can you post the error messages?
I now see embedding.o and extending.o in the bin/gcc-4.01/debug directory within the quickstart directory. But when I run test_extending.py, the script fails and gives "ImportError: No module named extending". How do I get the python script to import the extending module?
In Christ, Steven Watanabe
On Mon, Feb 23, 2009 at 9:40 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
Something failed to build. Can you post the error messages?
Sure, here's the full output: $ ./bjam toolset=gcc --verbose-test test ...patience... ...patience... ...found 1356 targets... ...updating 54 targets... common.mkdir bin common.mkdir bin/test_ext.test common.mkdir bin/test_ext.test/gcc-4.0.1 common.mkdir bin/test_ext.test/gcc-4.0.1/debug common.mkdir bin/gcc-4.0.1 common.mkdir bin/gcc-4.0.1/debug gcc.compile.c++ bin/gcc-4.0.1/debug/extending.o common.mkdir ../../../../bin.v2 common.mkdir ../../../../bin.v2/libs common.mkdir ../../../../bin.v2/libs/python common.mkdir ../../../../bin.v2/libs/python/build common.mkdir ../../../../bin.v2/libs/python/build/gcc-4.0.1 common.mkdir ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/numeric.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/list.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/long.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/dict.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/tuple.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/str.o ../../../../libs/python/src/str.cpp: In function ‘boost::python::ssize_t boost::python::detail::<unnamed>::str_size_as_py_ssize_t(size_t)’: ../../../../libs/python/src/str.cpp:29: warning: comparison between signed and unsigned integer expressions gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/slice.o common.mkdir ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/from_python.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/registry.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/type_id.o common.mkdir ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/enum.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/class.o ../../../../libs/python/src/object/class.cpp: In function ‘boost::python::api::object boost::python::objects::<unnamed>::new_class(const char*, size_t, const boost::python::type_info*, const char*)’: ../../../../libs/python/src/object/class.cpp:510: warning: comparison between signed and unsigned integer expressions gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/function.o ../../../../libs/python/src/object/function.cpp: In member function ‘PyObject* boost::python::objects::function::call(PyObject*, PyObject*) const’: ../../../../libs/python/src/object/function.cpp:169: warning: comparison between signed and unsigned integer expressions gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/inheritance.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/life_support.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/pickle_support.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/errors.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/module.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/builtin_converters.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/arg_to_python_base.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/iterator.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/stl_iterator.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object_protocol.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object_operators.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/wrapper.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/import.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/exec.o gcc.compile.c++ ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/function_doc_signature.o gcc.link.dll ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/libboost_python-gcc40-d-1_38.dylib ld: unknown option: -R collect2: ld returned 1 exit status "g++" -L"/System/Library/Frameworks/Python.framework/Versions/2.5/lib" -L"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config" -Wl,-R -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.5/lib" -Wl,-R -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config" -o "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/libboost_python-gcc40-d-1_38.dylib" -Wl,-h -Wl,libboost_python-gcc40-d-1_38.dylib -shared -Wl,--start-group "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/numeric.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/list.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/long.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/dict.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/tuple.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/str.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/slice.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/from_python.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/registry.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/type_id.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/enum.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/class.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/function.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/inheritance.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/life_support.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/pickle_support.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/errors.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/module.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/builtin_converters.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/converter/arg_to_python_base.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/iterator.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/stl_iterator.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object_protocol.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object_operators.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/wrapper.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/import.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/exec.o" "../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/object/function_doc_signature.o" -Wl,-Bstatic -Wl,-Bdynamic -lpython2.5 -Wl,--end-group -g ...failed gcc.link.dll ../../../../bin.v2/libs/python/build/gcc-4.0.1/debug/libboost_python-gcc40-d-1_38.dylib... ...skipped <pbin/gcc-4.0.1/debug>extending.so for lack of <p../../../../bin.v2/libs/python/build/gcc-4.0.1/debug>libboost_python-gcc40-d-1_38.dylib... ...skipped <pbin/test_ext.test/gcc-4.0.1/debug>test_ext for lack of <pbin/gcc-4.0.1/debug>extending.so... common.mkdir bin/test_embed.test common.mkdir bin/test_embed.test/gcc-4.0.1 common.mkdir bin/test_embed.test/gcc-4.0.1/debug gcc.compile.c++ bin/gcc-4.0.1/debug/embedding.o ...skipped <pbin/gcc-4.0.1/debug>embedding for lack of <p../../../../bin.v2/libs/python/build/gcc-4.0.1/debug>libboost_python-gcc40-d-1_38.dylib... ...skipped <pbin/test_embed.test/gcc-4.0.1/debug>test_embed.run for lack of <pbin/gcc-4.0.1/debug>embedding... ...failed updating 1 target... ...skipped 6 targets... ...updated 47 targets...
AMDG Z. S. O. wrote:
On Mon, Feb 23, 2009 at 9:40 PM, Steven Watanabe <watanabesj@gmail.com <mailto:watanabesj@gmail.com>> wrote:
Something failed to build. Can you post the error messages?
Sure, here's the full output:
$ ./bjam toolset=gcc --verbose-test test
Use toolset=darwin, that should at least get the library to build. In Christ, Steven Watanabe
For some reason, when I do toolset=darwin it gets stuck at one part of the build process. I left it on overnight and it still looks like this: $ ./bjam toolset=darwin --verbose-test test ...patience... ...patience... ...found 1356 targets... ...updating 17 targets... common.mkdir bin common.mkdir bin/test_ext.test common.mkdir bin/test_ext.test/darwin-4.0.1 common.mkdir bin/test_ext.test/darwin-4.0.1/debug common.mkdir bin/darwin-4.0.1 common.mkdir bin/darwin-4.0.1/debug darwin.compile.c++ bin/darwin-4.0.1/debug/extending.o darwin.link.dll bin/darwin-4.0.1/debug/extending.so It still hasn't given me back my prompt, so I don't know what's going on. On Mon, Feb 23, 2009 at 11:55 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Z. S. O. wrote:
On Mon, Feb 23, 2009 at 9:40 PM, Steven Watanabe <watanabesj@gmail.com<mailto: watanabesj@gmail.com>> wrote:
Something failed to build. Can you post the error messages?
Sure, here's the full output:
$ ./bjam toolset=gcc --verbose-test test
Use toolset=darwin, that should at least get the library to build.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG Z. S. O. wrote:
For some reason, when I do toolset=darwin it gets stuck at one part of the build process. I left it on overnight and it still looks like this:
$ ./bjam toolset=darwin --verbose-test test ...patience... ...patience... ...found 1356 targets... ...updating 17 targets... common.mkdir bin common.mkdir bin/test_ext.test common.mkdir bin/test_ext.test/darwin-4.0.1 common.mkdir bin/test_ext.test/darwin-4.0.1/debug common.mkdir bin/darwin-4.0.1 common.mkdir bin/darwin-4.0.1/debug darwin.compile.c++ bin/darwin-4.0.1/debug/extending.o darwin.link.dll bin/darwin-4.0.1/debug/extending.so
It still hasn't given me back my prompt, so I don't know what's going on.
Interrupt it. bjam is holding on to the output from whatever it's running. I want to see what command is actually looping. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Z. S. O. wrote:
For some reason, when I do toolset=darwin it gets stuck at one part of the build process. I left it on overnight and it still looks like this:
$ ./bjam toolset=darwin --verbose-test test ...patience... ...patience... ...found 1356 targets... ...updating 17 targets... common.mkdir bin common.mkdir bin/test_ext.test common.mkdir bin/test_ext.test/darwin-4.0.1 common.mkdir bin/test_ext.test/darwin-4.0.1/debug common.mkdir bin/darwin-4.0.1 common.mkdir bin/darwin-4.0.1/debug darwin.compile.c++ bin/darwin-4.0.1/debug/extending.o darwin.link.dll bin/darwin-4.0.1/debug/extending.so
It still hasn't given me back my prompt, so I don't know what's going on.
Interrupt it. bjam is holding on to the output from whatever it's running. I want to see what command is actually looping.
It's probably this: https://svn.boost.org/trac/boost/ticket/2185 Hard to know what's going on -- it's working for some folks, so somebody has to poke in a debugger. - Volodya
On Tue, Feb 24, 2009 at 11:47 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Interrupt it. bjam is holding on to the output from whatever it's running. I want to see what command is actually looping.
Not sure how to interrupt a command line. Google says I should just type "\" and enter but that does nothing. On Tue, Feb 24, 2009 at 12:03 PM, Vladimir Prus <vladimir@codesourcery.com>wrote:
It's probably this:
https://svn.boost.org/trac/boost/ticket/2185
Hard to know what's going on -- it's working for some folks, so somebody has to poke in a debugger.
Strange...Is there a way to bypass bjam altogether? I was hoping to build my wrapper in Eclipse and compile it as a shared library, but it looks like there's no way to do it like that.
AMDG Z. S. O. wrote:
On Tue, Feb 24, 2009 at 11:47 AM, Steven Watanabe <watanabesj@gmail.com <mailto:watanabesj@gmail.com>> wrote:
AMDG
Interrupt it. bjam is holding on to the output from whatever it's running. I want to see what command is actually looping.
Not sure how to interrupt a command line. Google says I should just type "\" and enter but that does nothing.
control-D.
On Tue, Feb 24, 2009 at 12:03 PM, Vladimir Prus <vladimir@codesourcery.com <mailto:vladimir@codesourcery.com>> wrote:
It's probably this:
https://svn.boost.org/trac/boost/ticket/2185
Hard to know what's going on -- it's working for some folks, so somebody has to poke in a debugger.
Strange...Is there a way to bypass bjam altogether? I was hoping to build my wrapper in Eclipse and compile it as a shared library, but it looks like there's no way to do it like that.
The shared library seems to build ok. Does bjam hang if you just build it? bjam toolset=darwin embedding In Christ, Steven Watanabe
On Tue, Feb 24, 2009 at 3:56 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
The shared library seems to build ok. Does bjam hang if you just build it? bjam toolset=darwin embedding
That command works fine, no hanging at all. It also works if I do "bjam toolset=darwin extending". How would I go about importing this shared library into a python script? Is it as making a python script in the same directory as the .so file, and typing "from extending import *"?
AMDG Z. S. O. wrote:
On Tue, Feb 24, 2009 at 3:56 PM, Steven Watanabe <watanabesj@gmail.com <mailto:watanabesj@gmail.com>> wrote:
The shared library seems to build ok. Does bjam hang if you just build it? bjam toolset=darwin embedding
That command works fine, no hanging at all. It also works if I do "bjam toolset=darwin extending". How would I go about importing this shared library into a python script? Is it as making a python script in the same directory as the .so file, and typing "from extending import *"?
I think that would work. The PYTHONPATH variable controls where python looks for extension modules as well as plain .py modules. In Christ, Steven Watanabe
Hmm, I've made some progress but not quite there. If you cd to the directory with extending.so and bring up the python interpreter, typing "from extending import *" leads to the following: Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: dlopen(./extending.so, 2): Library not loaded: libboost_python-xgcc40-d-1_38.dylib Referenced from: /Users/Admin/Desktop/boost_1_38_0/libs/python/example/quickstart/bin/darwin-4.0.1/debug/extending.so Reason: image not found Very sorry for prolonging this thread, I really appreciate the help so far. On Tue, Feb 24, 2009 at 8:37 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Z. S. O. wrote:
On Tue, Feb 24, 2009 at 3:56 PM, Steven Watanabe <watanabesj@gmail.com<mailto: watanabesj@gmail.com>> wrote:
The shared library seems to build ok. Does bjam hang if you just build it? bjam toolset=darwin embedding
That command works fine, no hanging at all. It also works if I do "bjam toolset=darwin extending". How would I go about importing this shared library into a python script? Is it as making a python script in the same directory as the .so file, and typing "from extending import *"?
I think that would work. The PYTHONPATH variable controls where python looks for extension modules as well as plain .py modules.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG Z. S. O. wrote:
Hmm, I've made some progress but not quite there. If you cd to the directory with extending.so and bring up the python interpreter, typing "from extending import *" leads to the following:
Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: dlopen(./extending.so, 2): Library not loaded: libboost_python-xgcc40-d-1_38.dylib Referenced from: /Users/Admin/Desktop/boost_1_38_0/libs/python/example/quickstart/bin/darwin-4.0.1/debug/extending.so Reason: image not found
Very sorry for prolonging this thread, I really appreciate the help so far.
I believe that the location of the boost python library needs to be in DYLD_LIBRARY_PATH. In Christ, Steven Watanabe
But hasn't it already successfully compiled? The location of boost shouldn't matter at this point. On Tue, Feb 24, 2009 at 9:22 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Z. S. O. wrote:
Hmm, I've made some progress but not quite there. If you cd to the directory with extending.so and bring up the python interpreter, typing "from extending import *" leads to the following:
Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: dlopen(./extending.so, 2): Library not loaded: libboost_python-xgcc40-d-1_38.dylib Referenced from: /Users/Admin/Desktop/boost_1_38_0/libs/python/example/quickstart/bin/darwin-4.0.1/debug/extending.so Reason: image not found
Very sorry for prolonging this thread, I really appreciate the help so far.
I believe that the location of the boost python library needs to be in DYLD_LIBRARY_PATH.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Got it! I searched spotlight for "libboost_python-xgcc40-d-1_38.dylib" and moved it into the same directory as extending.so and now I can import it just fine. Thank you so much!! On Tue, Feb 24, 2009 at 9:27 PM, Z. S. O. <tiredashell@gmail.com> wrote:
But hasn't it already successfully compiled? The location of boost shouldn't matter at this point.
On Tue, Feb 24, 2009 at 9:22 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Z. S. O. wrote:
Hmm, I've made some progress but not quite there. If you cd to the directory with extending.so and bring up the python interpreter, typing "from extending import *" leads to the following:
Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: dlopen(./extending.so, 2): Library not loaded: libboost_python-xgcc40-d-1_38.dylib Referenced from: /Users/Admin/Desktop/boost_1_38_0/libs/python/example/quickstart/bin/darwin-4.0.1/debug/extending.so Reason: image not found
Very sorry for prolonging this thread, I really appreciate the help so far.
I believe that the location of the boost python library needs to be in DYLD_LIBRARY_PATH.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
Steven Watanabe -
Vladimir Prus -
Z. S. O.