[petsc-dev] Compiling C code with C compiler

[Barry Smith]

On Apr 4, 2011, at 9:50 PM, Lisandro Dalcin wrote:

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

    No, in 3.1 it only ever does the dlopen() if --with-dynamic flag is set. In petsc-dev if BuildSystem "thinks" that dlopen() works it will do dlopen().
>> 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?

   The culprit himself :-) Apparently dlopen(0,flags) doesn't work on some systems but BuildSystem has no check for this (it only checks that dlopen(somelibrary,flags) works). Your code that always turns on PETSC_HAVE_DYNAMIC_LIBRARIES causes the dlopen(0,flags) to be used and hence cause grief.  The fix is, of course, to add the additional check to BuildSystem. But Matt aparently forgot his laptop when he went out to the bar tonight so hasn't seen the discussion yet.

   Barry



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