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
