On Mon, Apr 4, 2011 at 9:33 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > On Apr 4, 2011, at 9:25 PM, Sean Farley wrote: > > > What did you expect when you used --with-clanguage=C++ for your buid? Or > > were you misunderstanding what this options means wrt PETSc build? > > > > I understand what it was trying to do but it is necessary for sieve > (especially with certain mesh generators). Why does all of PETSc need to be > compiled with C++ in order to use sieve is the real question? > > Since the sieve c++ compiled code uses the C code (like VecXXX) the C++ > compiler would have to know that the other parts of C are not compiled with > C++. At a minimum you would have to extern c it in the header files other > wise the C++ compiled code will call the C routines with name-mangling > turned on while the C compiler doesn't know about name mangling and hence > would generate routines without name mangling and the c++ code wouldn't find > the c routines. In other words, even without issues of struct layouts > currently everything in PETSc needs to be built with the same compiler. If > sieve was made a completely separate package form PETSc then one could > easily arrange things so that sieve compiled with c++ and PETSc with c. > > Why is everyone talking about this unimportant issue when we got serious > dlopen() issues to fix? > It seems to me that on Jaguar passing in a 0 handle should work, since that's what 3.1 does (I'm not sure about 3.1-p4, though). Also, if we are interested in comparing performance, why not just build 3.1 without shared? Dmitry. > > Barry > > > > > .c -> compiled with mpicc > > .cxx -> compiled with mpicxx > > > > Is there something else missing? (Perhaps linking?) > > > > Sean > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110404/12995090/attachment.html>
