<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 6:02 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2qi">   We have --with-clanguage=c or c++   (this is already weird, most packages don't strife to be built either with C or C++)<br>

                  --with-c-support=0,1             (compile with C++ but with C bindings so C application can use it)<br>
<br>
              User Code                PETSc compiled with<br>
          ------------------------          C                  C++<br>
                    C                           x                   x<br>
                    C++                       x                   x<br>
<br>
            Hope back into Satish's way back machine and ask the question "why do we have this c-support business"? Seems like it complicates<br>
life a lot?</div></blockquote></div><br>I would just unconditionally use extern "C" when compiling PETSc with a C++ compiler. We don't use overloading (PetscPolymorphic* was removed last spring) so I don't think there is any functional reason to mangle symbols. AFAICT, the only functional reason for building PETSc with a C++ compiler is to use C++ complex (and perhaps because the C++ compiler catches different errors than the C compiler).</div>
</div>