[petsc-dev] Compiling C code with C compiler

[Lisandro Dalcin]

On 4 April 2011 23:46:38 UTC-3, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>
>
> On Mon, Apr 4, 2011 at 9:33 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>> On Apr 4, 2011, at 9:25 PM, Sean Farley wrote:
>>
>> > What did you expect when you used --with-clanguage=C++ for your buid? Or
>> > were you misunderstanding what this options means wrt PETSc build?
>> >
>> > I understand what it was trying to do but it is necessary for sieve
>> > (especially with certain mesh generators). Why does all of PETSc need to be
>> > compiled with C++ in order to use sieve is the real question?
>>
>>   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. 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.
>>
>>   Why is everyone talking about this unimportant issue when we got serious
>> dlopen() issues to fix?
>
> It seems to me that on Jaguar passing in a 0 handle should work, since
> that's what 3.1 does (I'm not sure about 3.1-p4, though).
> Also, if we are interested in comparing performance, why not just build 3.1
> without shared?
> Dmitry.
>

Sorry, what dlopen() issues are you talking about?


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