[petsc-dev] Compiling C code with C compiler

[Matthew Knepley]

On Tue, Apr 5, 2011 at 7:36 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   Jed,
>
>     If it is as simple as you say then I am fine with adding support BUT it
> will require "yet another flag" and hence increase complexity.
> --with-c-for-c-code=1 or something and either require a compiler that is
> smart enough to switch based on extension or two lists of files to compile
> with the two compilers. These choices are already complicated for some users
> and the logic in PETSc will get messy.


I actually want the code compiled with the C++ compiler. That is what the
option said and that is what I want. You can
want something else, so make a different option for it. This is exactly what
users requested and we implemented.

Can someone give a 1 line description of the dlopen() test they want and I
will put it in today.

    Matt


>
>    Barry
>
> On Apr 5, 2011, at 2:03 AM, Jed Brown wrote:
>
> > 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.
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110405/d6891551/attachment.html>