On Mon, Apr 4, 2011 at 9:33 PM, Barry Smith <[email protected]> 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