← Back to team overview

dolfin team mailing list archive

Re: Some shared_ptr information

 

Johan Hake wrote:
> Hello!
> 
> After I added shared_ptr support for PyDOLFIN things have stabelized, I 
> think... but there are some issues you should be aware of. We need swig 
> version 1.3.35 or higher. This version comes with ubuntu 08.10 (intrepid). 
> Johannes are going to compile the newest swig, 1.3.37 and put it in our apt 
> repositories. I assume this also will be done for ubuntu 08.10? This last 
> version came this week, and it comes with a fix for std::tr1::shared_ptr, 
> making it possible to change back to tr1.
> 
> The nice thing with shared_ptrs in PyDOLFIN is that we no longer have to keep 
> any references for instances we do not want to get garbage collected in 
> python, as swig now use a shared_ptr to store the underlying c++ instance. 
> And of course it interact better with the c++ library which now use 
> shared_ptrs quite heavily.

I am running into some troubles with the JIT compiler after these recent
changes. I have Swig 1.3.35 and have run instant-clean.

When I try to run a(ny) python demo, it fails with a 'module did not
compile' and points me to a log file. Here is its head:

running build_ext
building '_form_631c2971bc63dc564a258685317dbc7c19bb5b84' extension
creating build
creating build/temp.macosx-10.5-i386-2.5
gcc -fno-strict-aliasing -Wno-long-double -mno-fused-madd -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes
-I/Users/hnarayan/Work/FEniCS/build/include -I/sw/include/python2.5 -c
form_631c2971bc63dc564a258685317dbc7c19bb5b84_wrap.cxx -o
build/temp.macosx-10.5-i386-2.5/form_631c2971bc63dc564a258685317dbc7c19bb5b84_wrap.o
-O0
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
C/ObjC but not for C++
form_631c2971bc63dc564a258685317dbc7c19bb5b84_wrap.cxx:2625:33: error:
boost/shared_ptr.hpp: No such file or directory
form_631c2971bc63dc564a258685317dbc7c19bb5b84_wrap.cxx:2640: error:
‘boost’ has not been declared

... many more related errors.

The compiler flags seem to be missing a -I/where/boost/includes/are and
-L/where/boost/libs/are . They are present in the corresponding scons
compile/link lines for the C++ demos which do not have this problem.

Harish


Follow ups

References