[petsc-dev] Compiling C code with C compiler

[Lisandro Dalcin]

On 5 April 2011 10:22, Matthew Knepley <knepley at gmail.com> wrote:
> 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.

--with-c++-support=1 ? This should compile .c with C and .cpp/.cxx
with C++, and it should be enabled by default.

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

I think that the following code should do

#include <dlfcn.h>
int main() {
void* handle;
dlerror();
handle = dlopen(0, RTLD_LAZY|RTLD_LOCAL);
if (!handle || dlerror()) return 1; /*fail, cannot dlopen executable*/
return 0;
}

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



-- 
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169