[petsc-dev] Compiling C code with C compiler

[Dmitry Karpeev]

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>