[petsc-dev] Compiling C code with C compiler

[Jed Brown]

On Tue, Apr 5, 2011 at 04:33, Barry Smith <bsmith at mcs.anl.gov> wrote:

> 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.


But this is already what happens --with-c-support. Why is it ever necessary
to compile the C source with a C++ compiler (that is, why support
with-c-support=0)? The C++ convenience functions (PetscPolymorphicFunction)
can easily be defined whenever a C++ compiler is used, they will be name
mangled (and usually inlined). I think all you would need to do is remove
the PETSC_USE_EXTERN_CXX clause from

#if !defined(PETSC_USE_EXTERN_CXX) && defined(__cplusplus)


> 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.


I don't see any complexity in always building C source with a C compiler and
C++ source with a C++ compiler. It seems simpler to me. And then people
could build a PETSc that includes Sieve and still call it from C (e.g. when
they happen to not be using Sieve).


The only problem I can think of, and which might be justification for
building C code with a C++ compiler, is that C++ compilers seem to be
stricter about complex. C99 complex is binary compatible with C++ complex,
but type checking is weaker. I don't know if this is implicit in the
standard or if the GNU compilers are unnecessarily lenient about C99
complex. This is purely a matter of quality error/warning messages, but I'm
loathe to give up any static type checking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110405/4d82af0b/attachment.html>