Re: [C++-sig] boost::python and threads
Hiya, That's fantastic, all I needed to do was to put PyGILState_Ensure(); before my virtual function calls into python from another thread and my program no longer crashes. Problem solved, isn't boost::python great! Many thanks, Paul "Renato Araujo" wrote in message news:[email protected]... Hi Paul In my bindings I had a problem like this, to solve I created a simple class like that: class thread_locker { thread_locker() { if (thread_support::enabled()) m_gstate = PyGILState_Ensure(); } ~thread_locker() { if (thread_support::enabled()) PyGILState_Release(m_gstate); } }; then in my wrapper virtual implementation I did this: ... void wrapper::virtual_func(..) { thread_locker lock; .. my code .. } this solve my problems with call of virtual functions in thread enviroment. BR On Sat, Jul 4, 2009 at 5:03 PM, William Ladwig wrote: > Whoops, I think this problem is a little uglier than I thought, since you > overrode the onTick() function in python with a call to print, which needs > access to the interpreter in your new thread. See the link Thomas posted > for dealing with the GIL (along with worrying about any possible garbage > collection issues). Now I remember why I kept my C++ threads isolated from > Python stuffsorry, it's been a while > > Bill > > From: [email protected] > [[email protected]] On Behalf Of William > Ladwig [[email protected]] > Sent: Saturday, July 04, 2009 1:34 PM > To: Development of Python/C++ integration > Subject: Re: [C++-sig] boost::python and threads > > It looks to me like you have a garbage collection problem going on. If you > create a wrapped c++ object in python, then python is going to own the > object and will destroy it when its reference count goes to 0. In your > python example script at the bottom, you call the Ticker's run() function, > which from the python point of view, returns quickly and the script ends. > Python has no idea that you spawned off a new thread from the C++ side, so > when the script ends, python destroys the object and now you have a > problem. One way that you can check to see if this is what is going on is > to add this to the bottom of the test script and see if the crashes go > away: > > # Warning, you'll need to kill this script manually > import time > while True: > time.sleep(1) > > Generally when I want to fire off a new C++ thread, I hold any objects > that the thread needs in an auto_ptr (see held type for class wrappers), > take ownership of them in C++ (see the FAQ in the documentation) and start > the thread from the C++ side. Or, you can also create C++ wrappers which > accept shared_ptr arguments, while holding your classes in shared_ptrs, > and this should handle the reference counting as well. Unfortunately, this > may require some interface changes to what you have already written (or > possibly some clever wrapping). > > Hope this helps, > Bill > > > > From: [email protected] > [[email protected]] On Behalf Of Paul > Scruby [[email protected]] > Sent: Friday, July 03, 2009 6:15 AM > To: [email protected] > Subject: [C++-sig] boost::python and threads > > I am having some problems using boost::python with boost::thread. I'm > using > threads because I want to run some tasks in the background when I'm using > the Python's interactive shell. However, when I use get_override() to call > a Python method from another boost::thread it crashes internally. For > example: > > #include > #include > #include > > using namespace boost::python; > > class Ticker > : public wrapper > { > private: > bool run_; > volatile bool * running_; > boost::thread * thread_; > boost::xtime xt_; > public: > Ticker() : running_(&run_) { *running_ = false; } > > void operator()() > { > while (*running_) > { > boost::xtime_get(&xt_, boost::TIME_UTC); > ++xt_.sec; > boost::thread::sleep(xt_); > onTick(); > } > } > > void run() > { > if (*running_ == false) > { > *running_ = true; > thread_ = new boost::thread(*this); > } > } > > void stop() > { > if (*running_ == true) > { > *running_ = false; > thread_->join(); > delete thread_; > } > } > > virtual void onTick() { get_override("onTick")(); } > void default_onTick() {} > }; > > BOOST_PYTHON_MODULE(tick) > { > class_ ("Ticker") > .def("run", &Ticker::run) > .def("stop", &Ticker::stop) > .def("onTick", &Ticker::default_onTick); > } > > Here is a test script that which will crash when you import it into > Python's > interactive shell. > > from tick import Ticker > > class MyTicker(Ticker): > def onTick(self): > print "Each second" > > myticker = MyTicker() > myticker.run() > > I ran this test initially on Python 2.4.4 with the Sun C++ 5.9 compiler on > Solaris and I
Re: [C++-sig] boost::python and threads
Hello again, Sorry, I spoke too soon. The good news is that wrapping my virtual method calls into Python between PyGILState_Ensure() and PyGILState_Release() fixed the crash under Python2.6.2 on Windows, but not when I tested it again under Python 2.4.4 on Solaris. Under Python 2.4.4 on SolarisSolaris it now calls and exits the virtual method in Python sucessfully, but then crashes when C++ trys to release the global interpretor lock. The call-stack with the Sun C++ 5.9 compiler under Solaris is t...@2 (l...@2) signal SEGV (no mapping at the fault address) in sem_invalid at 0xfec453ed 0xfec453ed: sem_invalid+0x0013: movzwl 0x0006(%eax),%eax Current function is Ticker::operator() 28 PyGILState_Release(state_); (dbx) where current thread: t...@2 [1] sem_invalid(0x0), at 0xfec453ed [2] _sem_post(0x0), at 0xfec454c4 [3] PyThread_release_lock(0x0, 0xfe77ef2c, 0xfef43eba, 0x80c55c0, 0xfe77ef38, 0xfef441b5), at 0xfef492dc [4] PyEval_ReleaseLock(0x80c55c0, 0xfe77ef38, 0xfef441b5, 0xfeb12aec, 0xfe77ef70, 0xfeafb2e3), at 0xfef27abe [5] PyThreadState_DeleteCurrent(0xfeb12aec, 0xfe77ef70, 0xfeafb2e3, 0x1, 0x0, 0x80a3140), at 0xfef43eba [6] PyGILState_Release(0x1, 0x0), at 0xfef441b5 =>[7] Ticker::operator()(this = 0x810a304), line 28 in "ticker.cc" [8] boost::detail::thread_data::run(this = 0x810a288), line 56 in "thread.hpp" [9] thread_proxy(0x810a288), at 0xfea78ce4 [10] _thr_setup(0xfe670200), at 0xfee159b9 [11] _lwp_start(0xfe77ef08, 0xfec454c4, 0x0, 0xfe77ef54, 0x80c55c0, 0xfe77ef14), at 0xfee15ca0 Do you think it's worth repeating this test using gcc/linux, or do you think that this is just a limitation of using Python with threads? Thanks again, Paul t...@2 (l...@2) signal SEGV (no mapping at the fault address) in sem_invalid at 0xfec453ed 0xfec453ed: sem_invalid+0x0013: movzwl 0x0006(%eax),%eax Current function is Ticker::operator() 28 PyGILState_Release(state_); (dbx) where current thread: t...@2 [1] sem_invalid(0x0), at 0xfec453ed [2] _sem_post(0x0), at 0xfec454c4 [3] PyThread_release_lock(0x0, 0xfe77ef2c, 0xfef43eba, 0x80c55c0, 0xfe77ef38, 0xfef441b5), at 0xfef492dc [4] PyEval_ReleaseLock(0x80c55c0, 0xfe77ef38, 0xfef441b5, 0xfeb12aec, 0xfe77ef70, 0xfeafb2e3), at 0xfef27abe [5] PyThreadState_DeleteCurrent(0xfeb12aec, 0xfe77ef70, 0xfeafb2e3, 0x1, 0x0, 0x80a3140), at 0xfef43eba [6] PyGILState_Release(0x1, 0x0), at 0xfef441b5 =>[7] Ticker::operator()(this = 0x810a304), line 28 in "ticker.cc" [8] boost::detail::thread_data::run(this = 0x810a288), line 56 in "thread.hpp" [9] thread_proxy(0x810a288), at 0xfea78ce4 [10] _thr_setup(0xfe670200), at 0xfee159b9 [11] _lwp_start(0xfe77ef08, 0xfec454c4, 0x0, 0xfe77ef54, 0x80c55c0, 0xfe77ef14), at 0xfee15ca0 "Paul Scruby" wrote in message news:[email protected]... > Hiya, > > That's fantastic, all I needed to do was to put PyGILState_Ensure(); > before my virtual function calls into python from another thread and my > program no longer crashes. Problem solved, isn't boost::python great! > > Many thanks, > > Paul > > > "Renato Araujo" wrote in message > news:[email protected]... > Hi Paul > > In my bindings I had a problem like this, to solve I created a simple > class like that: > > class thread_locker > { > thread_locker() > { >if (thread_support::enabled()) >m_gstate = PyGILState_Ensure(); > } > > ~thread_locker() > { >if (thread_support::enabled()) >PyGILState_Release(m_gstate); > } > }; > > then in my wrapper virtual implementation I did this: > > ... > void wrapper::virtual_func(..) > { > thread_locker lock; > .. my code .. > } > > > this solve my problems with call of virtual functions in thread > enviroment. > > BR > > > > > On Sat, Jul 4, 2009 at 5:03 PM, William Ladwig wrote: >> Whoops, I think this problem is a little uglier than I thought, since you >> overrode the onTick() function in python with a call to print, which >> needs access to the interpreter in your new thread. See the link Thomas >> posted for dealing with the GIL (along with worrying about any possible >> garbage collection issues). Now I remember why I kept my C++ threads >> isolated from Python stuffsorry, it's been a while >> >> Bill >> >> From: [email protected] >> [[email protected]] On Behalf Of >> William Ladwig [[email protected]] >> Sent: Saturday, July 04, 2009 1:34 PM >> To: Development of Python/C++ integration >> Subject: Re: [C++-sig] boost::python and threads >> >> It looks to me like you have a garbage collection problem going on. If >> you create a wrapped c++ object in python, then python is going to own >> the object and will destroy it when its reference count goes to 0. In >> your pyth
Re: [C++-sig] boost::python and threads
I'm using gcc/linux and python >= 2.4 and works fine for me. On Mon, Jul 6, 2009 at 7:39 AM, Paul Scruby wrote: > Hello again, > > Sorry, I spoke too soon. The good news is that wrapping my virtual method > calls into Python between PyGILState_Ensure() and PyGILState_Release() fixed > the crash under Python2.6.2 on Windows, but not when I tested it again under > Python 2.4.4 on Solaris. Under Python 2.4.4 on SolarisSolaris it now calls > and exits the virtual method in Python sucessfully, but then crashes when > C++ trys to release the global interpretor lock. > > The call-stack with the Sun C++ 5.9 compiler under Solaris is > �...@2 (l...@2) signal SEGV (no mapping at the fault address) in sem_invalid > at 0xfec453ed > 0xfec453ed: sem_invalid+0x0013: movzwl 0x0006(%eax),%eax > Current function is Ticker::operator() > 28 PyGILState_Release(state_); > (dbx) where > current thread: t...@2 > [1] sem_invalid(0x0), at 0xfec453ed > [2] _sem_post(0x0), at 0xfec454c4 > [3] PyThread_release_lock(0x0, 0xfe77ef2c, 0xfef43eba, 0x80c55c0, > 0xfe77ef38, 0xfef441b5), at 0xfef492dc > [4] PyEval_ReleaseLock(0x80c55c0, 0xfe77ef38, 0xfef441b5, 0xfeb12aec, > 0xfe77ef70, 0xfeafb2e3), at 0xfef27abe > [5] PyThreadState_DeleteCurrent(0xfeb12aec, 0xfe77ef70, 0xfeafb2e3, 0x1, > 0x0, 0x80a3140), at 0xfef43eba > [6] PyGILState_Release(0x1, 0x0), at 0xfef441b5 > =>[7] Ticker::operator()(this = 0x810a304), line 28 in "ticker.cc" > [8] boost::detail::thread_data::run(this = 0x810a288), line 56 > in "thread.hpp" > [9] thread_proxy(0x810a288), at 0xfea78ce4 > [10] _thr_setup(0xfe670200), at 0xfee159b9 > [11] _lwp_start(0xfe77ef08, 0xfec454c4, 0x0, 0xfe77ef54, 0x80c55c0, > 0xfe77ef14), at 0xfee15ca0 > > Do you think it's worth repeating this test using gcc/linux, or do you think > that this is just a limitation of using Python with threads? > > Thanks again, > > Paul > > > t...@2 (l...@2) signal SEGV (no mapping at the fault address) in sem_invalid > at > 0xfec453ed > 0xfec453ed: sem_invalid+0x0013: movzwl 0x0006(%eax),%eax > Current function is Ticker::operator() > 28 PyGILState_Release(state_); > (dbx) where > current thread: t...@2 > [1] sem_invalid(0x0), at 0xfec453ed > [2] _sem_post(0x0), at 0xfec454c4 > [3] PyThread_release_lock(0x0, 0xfe77ef2c, 0xfef43eba, 0x80c55c0, > 0xfe77ef38, 0xfef441b5), at 0xfef492dc > [4] PyEval_ReleaseLock(0x80c55c0, 0xfe77ef38, 0xfef441b5, 0xfeb12aec, > 0xfe77ef70, 0xfeafb2e3), at 0xfef27abe > [5] PyThreadState_DeleteCurrent(0xfeb12aec, 0xfe77ef70, 0xfeafb2e3, 0x1, > 0x0, 0x80a3140), at 0xfef43eba > [6] PyGILState_Release(0x1, 0x0), at 0xfef441b5 > =>[7] Ticker::operator()(this = 0x810a304), line 28 in "ticker.cc" > [8] boost::detail::thread_data::run(this = 0x810a288), line 56 in > "thread.hpp" > [9] thread_proxy(0x810a288), at 0xfea78ce4 > [10] _thr_setup(0xfe670200), at 0xfee159b9 > [11] _lwp_start(0xfe77ef08, 0xfec454c4, 0x0, 0xfe77ef54, 0x80c55c0, > 0xfe77ef14), at 0xfee15ca0 > > > > "Paul Scruby" wrote in message > news:[email protected]... >> Hiya, >> >> That's fantastic, all I needed to do was to put PyGILState_Ensure(); >> before my virtual function calls into python from another thread and my >> program no longer crashes. Problem solved, isn't boost::python great! >> >> Many thanks, >> >> Paul >> >> >> "Renato Araujo" wrote in message >> news:[email protected]... >> Hi Paul >> >> In my bindings I had a problem like this, to solve I created a simple >> class like that: >> >> class thread_locker >> { >> thread_locker() >> { >> if (thread_support::enabled()) >> m_gstate = PyGILState_Ensure(); >> } >> >> ~thread_locker() >> { >> if (thread_support::enabled()) >> PyGILState_Release(m_gstate); >> } >> }; >> >> then in my wrapper virtual implementation I did this: >> >> ... >> void wrapper::virtual_func(..) >> { >> thread_locker lock; >> .. my code .. >> } >> >> >> this solve my problems with call of virtual functions in thread >> enviroment. >> >> BR >> >> >> >> >> On Sat, Jul 4, 2009 at 5:03 PM, William Ladwig wrote: >>> Whoops, I think this problem is a little uglier than I thought, since you >>> overrode the onTick() function in python with a call to print, which >>> needs access to the interpreter in your new thread. See the link Thomas >>> posted for dealing with the GIL (along with worrying about any possible >>> garbage collection issues). Now I remember why I kept my C++ threads >>> isolated from Python stuffsorry, it's been a while >>> >>> Bill >>> >>> From: [email protected] >>> [[email protected]] On Behalf Of >>> William Ladwig [[email protected]] >>> Sent: Saturday, July 04, 2009 1:34 PM >>> To: Development of Python/C++ integration >>> Subject: Re: [C++-sig] boost::pyt
[C++-sig] exposing pointer to Python
I have some class X that contains a variable which is a pointer to some
other class OtherClass (for simplicity we may imagine it can be some
standard c++ type - int, double, etc.):
class X{
public:
OtherClass* variable;
};
my question is: how can I expose it to python such that user may access to
variable using [] operator?
like:
>>> import module
>>> module.X[i] = i
I've found several examples on this topic:
http://mail.python.org/pipermail/cplusplus-sig/2005-January/008189.html
http://osdir.com/ml/python.c++/2003-01/msg00042.html
but still can not make this trick.
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Building with Scons
Hello, I am trying to build a python extension with scons but the resulting library cannot be loaded: ImportError: dynamic module does not define init function (initcylucene) I am using the following SConstruct file: FILES = ['typeconversion.cpp', 'document.cpp', 'search.cpp', 'queryparser.cpp', 'analysis.cpp', 'index.cpp', 'store.cpp', 'util.cpp'] def python_tool(env): pybase = 'python%s' % sys.version[0:3] env.Append(CPPPATH=[os.path.join(sys.prefix, 'include', pybase)], LIBPATH=[os.path.join(sys.prefix, 'lib', pybase, 'config')], LIBS=['lib%s' % pybase]) if env['PLATFORM'] not in ['cygwin', 'win32']: env.Append(LIBS=['util']) def boost_python_tool(env): env.Append(CPPDEFINES=['BOOST_PYTHON_DYNAMIC_LIB', 'BOOST_PYTHON_DYNAMIC_MODULE'], CPPPATH=['$boostIncludes'], # boostIncludes is a PathOption LIBS=['boost_python']) def clucene_tool(env): env.Append(CPPPATH=['/usr/local/lib/CLucene/', '/usr/local/lib/'], LIBS=['clucene']) import os env = Environment(ENV=os.environ, tools=['default', python_tool, boost_python_tool, clucene_tool]) env.SharedLibrary(target='cylucene', source=FILES, SHLIBPREFIX='') Previously I was using the following Makefile, which worked but was statically linked: SHELL = /bin/bash SRC = ./src/ BUILD = ./build/ INCLUDES = -I/usr/include/python2.6/ -I/usr/local/lib/ -I/usr/local/lib/CLucene/ LIBS = -lboost_python -lpython2.6 -lclucene CFLAGS = -shared -fPIC -g -pedantic -Wall -Wextra OBJECTS = document.o search.o queryparser.o analysis.o index.o store.o util.o LOBJECTS = $(BUILD)typeconversion.o $(BUILD)document.o $(BUILD)search.o $(BUILD)queryparser.o $(BUILD)analysis.o $(BUILD)index.o $(BUILD)store.o $(BUILD)util.o all: cylucene cylucene: $(OBJECTS) mkdir -p $(BUILD) && cp $(SRC)initfile.py $(BUILD)__init__.py $(CC) $(SRC)cylucene.cpp $(LOBJECTS) $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)cylucene.so document.o: typeconversion.o mkdir -p $(BUILD) $(CC) $(SRC)document.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)document.o queryparser.o: typeconversion.o mkdir -p $(BUILD) $(CC) $(SRC)queryparser.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)queryparser.o analysis.o: mkdir -p $(BUILD) $(CC) $(SRC)analysis.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)analysis.o search.o: mkdir -p $(BUILD) $(CC) $(SRC)search.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)search.o index.o: mkdir -p $(BUILD) $(CC) $(SRC)index.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)index.o store.o: mkdir -p $(BUILD) $(CC) $(SRC)store.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)store.o util.o: mkdir -p $(BUILD) $(CC) $(SRC)util.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)util.o typeconversion.o: mkdir -p $(BUILD) $(CC) $(SRC)typeconversion.cpp $(CFLAGS) -o $(BUILD)typeconversion.o clean: rm -Rf build/ Does anyone have experience working with scons and boost::python? Can anyone help? Thanks in advance! -- Nicolas Lara Linux user #380134 http://nicolas-lara.blogspot.com/ Public key id: 0x152e7713 at http://subkeys.pgp.net/ ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] exposing pointer to Python
take a look at:
http://www.boost.org/doc/libs/1_39_0/libs/python/doc/v2/indexing.html
BR
On Mon, Jul 6, 2009 at 8:07 PM, Alexey Akimov wrote:
> I have some class X that contains a variable which is a pointer to some
> other class OtherClass (for simplicity we may imagine it can be some
> standard c++ type - int, double, etc.):
>
> class X{
>
> public:
> OtherClass* variable;
>
> };
>
> my question is: how can I expose it to python such that user may access to
> variable using [] operator?
> like:
>
import module
module.X[i] = i
>
> I've found several examples on this topic:
> http://mail.python.org/pipermail/cplusplus-sig/2005-January/008189.html
> http://osdir.com/ml/python.c++/2003-01/msg00042.html
>
> but still can not make this trick.
>
>
>
>
>
>
> ___
> Cplusplus-sig mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>
--
Renato Araujo Oliveira Filho
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Building with Scons
Does the name of the module defined in your BOOST_PYTHON_MODULE section match the name of the .so file (assuming you are using Linux)? That's usually the error I get when I have a name mismatch. Also, I haven't really used scons, but shouldn't this: env.SharedLibrary(target='cylucene', source=FILES, SHLIBPREFIX='') be: env.SharedLibrary(target='cylucene', source=FILES, SHLIBPREFIX=''") ? Bill From: [email protected] [[email protected]] On Behalf Of Nicolas Lara [[email protected]] Sent: Monday, July 06, 2009 6:25 PM To: Development of Python/C++ integration Subject: [C++-sig] Building with Scons Hello, I am trying to build a python extension with scons but the resulting library cannot be loaded: ImportError: dynamic module does not define init function (initcylucene) I am using the following SConstruct file: FILES = ['typeconversion.cpp', 'document.cpp', 'search.cpp', 'queryparser.cpp', 'analysis.cpp', 'index.cpp', 'store.cpp', 'util.cpp'] def python_tool(env): pybase = 'python%s' % sys.version[0:3] env.Append(CPPPATH=[os.path.join(sys.prefix, 'include', pybase)], LIBPATH=[os.path.join(sys.prefix, 'lib', pybase, 'config')], LIBS=['lib%s' % pybase]) if env['PLATFORM'] not in ['cygwin', 'win32']: env.Append(LIBS=['util']) def boost_python_tool(env): env.Append(CPPDEFINES=['BOOST_PYTHON_DYNAMIC_LIB', 'BOOST_PYTHON_DYNAMIC_MODULE'], CPPPATH=['$boostIncludes'], # boostIncludes is a PathOption LIBS=['boost_python']) def clucene_tool(env): env.Append(CPPPATH=['/usr/local/lib/CLucene/', '/usr/local/lib/'], LIBS=['clucene']) import os env = Environment(ENV=os.environ, tools=['default', python_tool, boost_python_tool, clucene_tool]) env.SharedLibrary(target='cylucene', source=FILES, SHLIBPREFIX='') Previously I was using the following Makefile, which worked but was statically linked: SHELL = /bin/bash SRC = ./src/ BUILD = ./build/ INCLUDES = -I/usr/include/python2.6/ -I/usr/local/lib/ -I/usr/local/lib/CLucene/ LIBS = -lboost_python -lpython2.6 -lclucene CFLAGS = -shared -fPIC -g -pedantic -Wall -Wextra OBJECTS = document.o search.o queryparser.o analysis.o index.o store.o util.o LOBJECTS = $(BUILD)typeconversion.o $(BUILD)document.o $(BUILD)search.o $(BUILD)queryparser.o $(BUILD)analysis.o $(BUILD)index.o $(BUILD)store.o $(BUILD)util.o all: cylucene cylucene: $(OBJECTS) mkdir -p $(BUILD) && cp $(SRC)initfile.py $(BUILD)__init__.py $(CC) $(SRC)cylucene.cpp $(LOBJECTS) $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)cylucene.so document.o: typeconversion.o mkdir -p $(BUILD) $(CC) $(SRC)document.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)document.o queryparser.o: typeconversion.o mkdir -p $(BUILD) $(CC) $(SRC)queryparser.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)queryparser.o analysis.o: mkdir -p $(BUILD) $(CC) $(SRC)analysis.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)analysis.o search.o: mkdir -p $(BUILD) $(CC) $(SRC)search.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)search.o index.o: mkdir -p $(BUILD) $(CC) $(SRC)index.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)index.o store.o: mkdir -p $(BUILD) $(CC) $(SRC)store.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)store.o util.o: mkdir -p $(BUILD) $(CC) $(SRC)util.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)util.o typeconversion.o: mkdir -p $(BUILD) $(CC) $(SRC)typeconversion.cpp $(CFLAGS) -o $(BUILD)typeconversion.o clean: rm -Rf build/ Does anyone have experience working with scons and boost::python? Can anyone help? Thanks in advance! -- Nicolas Lara Linux user #380134 http://nicolas-lara.blogspot.com/ Public key id: 0x152e7713 at http://subkeys.pgp.net/ ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Building with Scons
Never mind, those single quotes looked like one double quote on my screen From: [email protected] [[email protected]] On Behalf Of William Ladwig [[email protected]] Sent: Monday, July 06, 2009 9:53 PM To: Development of Python/C++ integration Subject: Re: [C++-sig] Building with Scons Does the name of the module defined in your BOOST_PYTHON_MODULE section match the name of the .so file (assuming you are using Linux)? That's usually the error I get when I have a name mismatch. Also, I haven't really used scons, but shouldn't this: env.SharedLibrary(target='cylucene', source=FILES, SHLIBPREFIX='') be: env.SharedLibrary(target='cylucene', source=FILES, SHLIBPREFIX=''") ? Bill From: [email protected] [[email protected]] On Behalf Of Nicolas Lara [[email protected]] Sent: Monday, July 06, 2009 6:25 PM To: Development of Python/C++ integration Subject: [C++-sig] Building with Scons Hello, I am trying to build a python extension with scons but the resulting library cannot be loaded: ImportError: dynamic module does not define init function (initcylucene) I am using the following SConstruct file: FILES = ['typeconversion.cpp', 'document.cpp', 'search.cpp', 'queryparser.cpp', 'analysis.cpp', 'index.cpp', 'store.cpp', 'util.cpp'] def python_tool(env): pybase = 'python%s' % sys.version[0:3] env.Append(CPPPATH=[os.path.join(sys.prefix, 'include', pybase)], LIBPATH=[os.path.join(sys.prefix, 'lib', pybase, 'config')], LIBS=['lib%s' % pybase]) if env['PLATFORM'] not in ['cygwin', 'win32']: env.Append(LIBS=['util']) def boost_python_tool(env): env.Append(CPPDEFINES=['BOOST_PYTHON_DYNAMIC_LIB', 'BOOST_PYTHON_DYNAMIC_MODULE'], CPPPATH=['$boostIncludes'], # boostIncludes is a PathOption LIBS=['boost_python']) def clucene_tool(env): env.Append(CPPPATH=['/usr/local/lib/CLucene/', '/usr/local/lib/'], LIBS=['clucene']) import os env = Environment(ENV=os.environ, tools=['default', python_tool, boost_python_tool, clucene_tool]) env.SharedLibrary(target='cylucene', source=FILES, SHLIBPREFIX='') Previously I was using the following Makefile, which worked but was statically linked: SHELL = /bin/bash SRC = ./src/ BUILD = ./build/ INCLUDES = -I/usr/include/python2.6/ -I/usr/local/lib/ -I/usr/local/lib/CLucene/ LIBS = -lboost_python -lpython2.6 -lclucene CFLAGS = -shared -fPIC -g -pedantic -Wall -Wextra OBJECTS = document.o search.o queryparser.o analysis.o index.o store.o util.o LOBJECTS = $(BUILD)typeconversion.o $(BUILD)document.o $(BUILD)search.o $(BUILD)queryparser.o $(BUILD)analysis.o $(BUILD)index.o $(BUILD)store.o $(BUILD)util.o all: cylucene cylucene: $(OBJECTS) mkdir -p $(BUILD) && cp $(SRC)initfile.py $(BUILD)__init__.py $(CC) $(SRC)cylucene.cpp $(LOBJECTS) $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)cylucene.so document.o: typeconversion.o mkdir -p $(BUILD) $(CC) $(SRC)document.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)document.o queryparser.o: typeconversion.o mkdir -p $(BUILD) $(CC) $(SRC)queryparser.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)queryparser.o analysis.o: mkdir -p $(BUILD) $(CC) $(SRC)analysis.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)analysis.o search.o: mkdir -p $(BUILD) $(CC) $(SRC)search.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)search.o index.o: mkdir -p $(BUILD) $(CC) $(SRC)index.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)index.o store.o: mkdir -p $(BUILD) $(CC) $(SRC)store.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)store.o util.o: mkdir -p $(BUILD) $(CC) $(SRC)util.cpp $(INCLUDES) $(LIBS) $(CFLAGS) -o $(BUILD)util.o typeconversion.o: mkdir -p $(BUILD) $(CC) $(SRC)typeconversion.cpp $(CFLAGS) -o $(BUILD)typeconversion.o clean: rm -Rf build/ Does anyone have experience working with scons and boost::python? Can anyone help? Thanks in advance! -- Nicolas Lara Linux user #380134 http://nicolas-lara.blogspot.com/ Public key id: 0x152e7713 at http://subkeys.pgp.net/ ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
