<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 6:34 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra">I was asking about the second block. I don't understand why we would ever want the C header to be broken when include from C++.</div>
</div>
</blockquote></div></div><br>Broken? My interpretation was that this define was turning on extern C for the interface.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>The meaning of configureExternC changed from clanguage=C++ with-c-support to clanguage=C here:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://bitbucket.org/petsc/petsc-dev/commits/4b6962c351cf8206afe8cedb48495b4fffc8fa18">https://bitbucket.org/petsc/petsc-dev/commits/4b6962c351cf8206afe8cedb48495b4fffc8fa18</a><br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div>Anyway, "broken" would be when clanguage=C (so the library automatically extern "C"), but the header is include in a C++ project and extern "C" is not used. I started using PETSc back when this did not work automatically.</div>

</div>