Mailman 3 December 2010 - Cplusplus-sig

boost::python embedding error - runtime - Mac OS X - 1.38
by Igor Karpov Oct. 1, 2014

Oct. 1, 2014

Hi, I am trying to run the following program: #include <iostream> #include <Python.h> #include <boost/python.hpp> using namespace boost::python; using namespace std; int main(int argc, char** argv) { { // Using Python/C Py_Initialize(); PyObject* main_module = PyImport_ImportModule("__main__"); PyObject* globals = PyEval_GetGlobals(); PyObject* locals = PyEval_GetLocals(); PyRun_SimpleString("print 'Hello World, from Python/C!'\n"); Py_Finalize(); } { // Using boost::python Py_Initialize(); object main_module = import("__main__"); object main_namespace = main_module.attr("__dict__"); try { object ignored = exec("print 'Hello World, from boost::python!'\n", main_namespace); Py_Finalize(); } catch (error_already_set const& e) { PyErr_Print(); return 1; } } return 0; } on Linux (both x86 and x86_64), with Ubuntu's default version of Boost (1.34.1) installed, I am able to do so as expected: $ ./embed Hello World, from Python/C! Hello World, from boost::python! on Mac OS X, I get a runtime error: $ ./embed Hello World, from Python/C! Bus Error Running with gdb, this is the stack trace: Hello World, from Python/C! Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x00bb618f in PyEval_GetGlobals () #2 0x00bce0dd in PyImport_Import () #3 0x00bce2b0 in PyImport_ImportModule () #4 0x008127d4 in boost::python::import (name=@0xbffff4a8) at libs/python/src/import.cpp:20 #5 0x00004446 in main (argc=1, argv=0xbffff510) at embed.cc:22 For this Mac, boost version is latest (1.38) and python version is: Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Is this a bug? I attached the source and the cmake file I am using to build, for convenience. Thanks, --Igor.

4 6

CMake and getting starting with boost.python
by Braddock Gaskill Aug. 5, 2011

Aug. 5, 2011

Yesterday I became a boost.python user, after years of heavy SWIG usage. I would have started using boost.python years ago except for the bjam learning curve. I spent hours TRYING on multiple occasions, but got lost every time trying to get the page one example to build with bjam. Here is how to build the "greet" example with a four line CMake file: cat >>CMakeLists.txt <<EOF LINK_LIBRARIES(boost_python) INCLUDE_DIRECTORIES("/usr/include/python2.5") LINK_DIRECTORIES("/usr/lib/python2.5") # Not needed? ADD_LIBRARY(hello SHARED hello.cpp) EOF You WILL have to `mv libhello.so hello.so` after building. Works for me under Ubuntu Linux 6.10 after apt-get install cmake python2.5-dev boost-python-dev cmake make mv libhello.so hello.so ipython In [1]: import hello In [2]: hello.greet() Out[2]: 'hello, world' Boost.Python has been a joy to learn and use since I got past bjam. I had a moderately large API wrapped in just my first couple hours of learning (less time than I spent messing with bjam). Any additional advice for using CMake to build boost.python? Braddock Gaskill

4 4

How to import a boost::python dll in windows?
by ichijoji Aug. 5, 2011

Aug. 5, 2011

I'm trying to port some research code that uses boost::python to expose a library to python to windows, but I'm having trouble importing the dll into python. I'm compiling using msvc 2005 and using python 2.5, but when I try to import the module I get this: Traceback (most recent call last): File "main.py", line 1, in <module> import object File "c:\code\sge\code\scripts\object.py", line 1, in <module> import sge ImportError: No module named sge My module is named sge and I'm compiling to sge.dll. Is there some obvious reason why python wouldn't be able to find my dll? When I compile on linux into an so this code works fine. -- View this message in context: http://www.nabble.com/How-to-import-a-boost%3A%3Apython-dll-in-windows--tf3… Sent from the Python - c++-sig mailing list archive at Nabble.com.

4 4

Miscellaneous Boost.Python Utilities
by Jim Bosch July 6, 2011

July 6, 2011

In the hope that others might find them useful, and perhaps contribute some of their own, I've posted a collection of miscellaneous Boost.Python extensions I've been using at the Boost sandbox: http://svn.boost.org/svn/boost/sandbox/python_extensions Features include: - Conversions between STL containers and Boost.Range iterator ranges and Python builtins like list, tuple, and dict. - Conversions between Boost.Fusion sequences and Python tuples. - A third solution to the const shared_ptr problem (see http://language-binding.net/pyplusplus/troubleshooting_guide/shared_ptr/sha…) that isn't evil (I don't think) and doesn't involve changing the Boost.Python library itself - it simply doesn't use register_ptr_to_python to register the conversion. More info is available in the README file. Also, I'm sure many of the regulars on this list have their own similar extensions, and I'd love to see them collected in one place. If you'd like to add your collection to mine, or have a suggestion for some other place I should put my collection, please let me know. I would like to limit this collection to simple things that don't depend on non-Boost libraries, however. Jim Bosch

2 1

Boost.Python and python 3.x?
by Andrew Ho Jan. 2, 2011

Jan. 2, 2011

Hi, I'm trying to build Boost.Python to use Python 3.1, however I'm getting a bunch of errors (missing functions/members, etc.). I was able to get Boost.Python to compile correctly when using Python 2.6 so I don't think the problem is in my setup. I did a search and as far as I can tell there's no support for python 3.x being built at Boost 1.41, however I haven't found anything for Boost 1.45. There were references to a GSoC project to fix this, did this ever get finished? If so, is there something different between the Python 3.x and Python 2.x jam files that would cause this (other than referencing the correct includes & libs)? Here's my jam file for python 3.1 (C:\Python31 contains the source download of Python 3.1.2, built for Windows x64 release platforms): using msvc ; import os ; using python : 3.1 : # sources C:\\Python31 : # requirements <include>C:\\Python31\\Include <include>C:\\Python31\\PC <library-path>C:\\Python31\\PCBuild\\amd64 ; And I'm compile with this command: bjam link=static threading=multi address-model=64 variant=release toolset=msvc-9.0 -a --with-python

3 2

Boost.Python and python 3.x?
by Andrew Ho Dec. 30, 2010

Dec. 30, 2010

Hi, I'm trying to build Boost.Python to use Python 3.1, however I'm getting a bunch of errors (missing functions/members, etc.). I was able to get Boost.Python to compile correctly when using Python 2.6 so I don't think the problem is in my setup. I did a search and as far as I can tell there's no support for python 3.x being built at Boost 1.41, however I haven't found anything for Boost 1.45. There were references to a GSoC project to fix this, did this ever get finished? If so, is there something different between the Python 3.x and Python 2.x jam files that would cause this (other than referencing the correct includes & libs)? Here's my jam file for python 3.1 (C:\Python31 contains the source download of Python 3.1.2, built for Windows x64 release platforms): using msvc ; import os ; using python : 3.1 : # sources C:\\Python31 : # requirements <include>C:\\Python31\\Include <include>C:\\Python31\\PC <library-path>C:\\Python31\\ PCBuild\\amd64 ; And I'm compile with this command: bjam link=static threading=multi address-model=64 variant=release toolset=msvc-9.0 -a --with-python

1 0

Multiple calls to bp::detail::init_module() causing conflicts?
by Austin Bingham Dec. 25, 2010

Dec. 25, 2010

I'm in the process of upgrading my project to boost-1.45.0 and python3, and I started seeing strange problems with some of my boost.python-based extension modules. Essentially, some of my modules are reporting the wrong module name, i.e. if I "print(module_object.__name__)", I get the wrong value. I threw this into gdb, and it looks like the problem might have to do with the implementation of bp::detail::init_module(). I ran python under gdb, but a breakpoint on init_module(), and imported the modules with which I'm seeing problems. The first call to init_module() initializes the static PyModuleDef struct "moduledef" properly. However, the second call shows that the "m_name" field it left as-is from the first call (since the object is static); I would have expected that it needs to be updated with the new module name. This stale (I think) module def is then used for the rest of the initialization, and I'm guessing that this is the cause of the problems I'm seeing. Certainly, it seems that the name of the first module imported seems to be getting used as the name of the second module. I only noticed this problem when I tried to pickle some of the types exposed by my module. The pickle module in python3 complained that it didn't know anything about the broken modules I was getting. Is this a bug in boost.python? I plan to write a small patch tomorrow to set the m_name field in init_module(), so maybe this will fix the problem. If this isn't a boost.python bug, does anyone have any idea what might be going wrong? And how is it correct that the static moduledef is reused without updating its name? Thanks, Austin

3 6

builtin_converters.hpp using outdated API on win64 builds
by Austin Bingham Dec. 24, 2010

Dec. 24, 2010

I'm currently trying to build boost-1.45 against python-3.1.3 on win64 (visual studio 2009 sp1). This build is failing because boost/python/converter/builtin_converters.hpp is using APIs that have been removed from python3 without checking the python version; at lines 138 and 144 PyInt_FromLong is being used. If I understand what's going in that code, the fix is to update line 125 to check the python version. I think we can just add: && PY_VERSION_HEX < 0x03000000 to the preprocessor conditional. I've made this change locally, and it seems to fix things. Does this seem like the correct fix? If so, how do I get a patch to the right people (or at least ask them to make this change)? Austin

3 5

expose functor?
by Neal Becker Dec. 15, 2010

Dec. 15, 2010

Suppose I have a functor, e.g.: template<typename F> struct mag_sqr1 { F operator() (F z) { return (z * z); } }; Any way to expose this a a python function? def ("mag_sqr", ???);

1 0

Re: [C++-sig] problems with typedef void *
by Niall Douglas Dec. 14, 2010

Dec. 14, 2010

On 14 Dec 2010 at 14:07, Jacob Davis wrote: > I read through the thread back when I started work on this problem, but > figured if it had been scrubbed out it might not be wise to use it. I'll go > back and check it out soon, though. Trampoline types are a very commonly used idiom in C++ metaprogramming. They let you work around pre-C++0x limitations. > The last I saw on the subject, void > pointers were supposed to "just work", but I wonder if they "just work" > outside the context of a typedef obfuscation. If this doesn't work out, I'll > probably just do an extra layer of wrapping as Jim suggested. There is absolutely no reason why you can't declare all your typedefed void * as opaque pointers and get to work. The only problem will be that BPL won't know what to do with them (as they all look like void * and therefore are indistinguishable) and therefore can't touch them in any way except to pass them around unmodified. This probably won't be much use to you. I might add that another - and better solution - is to modify the C library to use proper opaque structures like you're supposed to in C rather than void * for everything. I would assume that below the header API its source is casting them to internal structures anyway, so you should be able to modify its header to use declared but not defined structs with the names that it's typedefing them to e.g. typedef void *EmoEngineEventHandle; ... this goes to: struct EmoEngineEventHandle_t; typedef struct EmoEngineEventHandle_t *EmoEngineEventHandle; Theoretically this should let you compile your C library just fine if it is indeed casting to internal structs. Even if it doesn't, it would be very easy to fix. It isn't 100% legal C or C++ though as it's type punning. However I can't think of a compiler which won't allow it. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909.

1 0