April 2011 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Compiling C code with C compiler
by Sean Farley 04 Apr '11

04 Apr '11

> > Sorry, what dlopen() issues are you talking about? It is a petsc-maint issue, which I don't think you are on that list. Sean

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Lisandro Dalcin 04 Apr '11

04 Apr '11

On 4 April 2011 23:46:38 UTC-3, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > > > On Mon, Apr 4, 2011 at 9:33 PM, Barry Smith <bsmith(a)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

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Lisandro Dalcin 04 Apr '11

04 Apr '11

On 4 April 2011 23:44, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > > > On Mon, Apr 4, 2011 at 9:32 PM, Jack Poulson <jack.poulson(a)gmail.com> wrote: >> >> On Mon, Apr 4, 2011 at 9:24 PM, Dmitry Karpeev <karpeev(a)mcs.anl.gov> >> wrote: >>> >>> struct _p_Mat { >>> PETSCHEADER(struct _MatOps); >>> PetscLayout rmap,cmap; >>> ... >>> } >>> typedef struct _p_Mat *Mat; >>> Mat A; >>> Now ((PetscObject)A)->comm is kosher, because of the way C lays out the >>> struct. >>> I don't know whether C++ does the same (there is the issue of where it >>> sticks the vtable, and I'm not sure what else). >>> I imagine there will be no problem, since we've been compiling the PETSc >>> C code with C++ compilers for a decade now, >>> but I don't know whether the C++ standard guarantees that. Jed is the >>> only person I know that actually reads the standard >>> (or maybe it's part of the ABI). >>> Dmitry. >> >> I would think that most compilers would not even use a vtable for C code >> since there are no virtual functions and no class derivations. On the other >> hand, it is my understanding that the way vtables are handled is not in the >> standard and is up to the compiler. Jed may know better even though he hates >> C++. > > If you take a piece of C code and compile it with a C++ compiler, then all > structs become classes. > Sure, if there are no virtual methods, no vtable will get generated, but the > mere possibility of having it there might force > the compiler to lay the rest of the crap out differently. As I said, > though, experience shows nothing like that happens. But some day, some guy will add something like this to PETSc: struct something { ... #ifdef __cplusplus virtual void foo() #endif } Barry's rant is going to be memorable :-) -- 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

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Dmitry Karpeev 04 Apr '11

04 Apr '11

On Mon, Apr 4, 2011 at 9:33 PM, Barry Smith <bsmith(a)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. > > Barry > > > > > .c -> compiled with mpicc > > .cxx -> compiled with mpicxx > > > > Is there something else missing? (Perhaps linking?) > > > > Sean > >

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Dmitry Karpeev 04 Apr '11

04 Apr '11

On Mon, Apr 4, 2011 at 9:32 PM, Jack Poulson <jack.poulson(a)gmail.com> wrote: > On Mon, Apr 4, 2011 at 9:24 PM, Dmitry Karpeev <karpeev(a)mcs.anl.gov>wrote: > >> >> struct _p_Mat { >> PETSCHEADER(struct _MatOps); >> PetscLayout rmap,cmap; >> ... >> } >> typedef struct _p_Mat *Mat; >> Mat A; >> Now ((PetscObject)A)->comm is kosher, because of the way C lays out the >> struct. >> I don't know whether C++ does the same (there is the issue of where it >> sticks the vtable, and I'm not sure what else). >> I imagine there will be no problem, since we've been compiling the PETSc C >> code with C++ compilers for a decade now, >> but I don't know whether the C++ standard guarantees that. Jed is the >> only person I know that actually reads the standard >> (or maybe it's part of the ABI). >> >> Dmitry. >> > > I would think that most compilers would not even use a vtable for C code > since there are no virtual functions and no class derivations. On the other > hand, it is my understanding that the way vtables are handled is not in the > standard and is up to the compiler. Jed may know better even though he hates > C++. > If you take a piece of C code and compile it with a C++ compiler, then all structs become classes. Sure, if there are no virtual methods, no vtable will get generated, but the mere possibility of having it there might force the compiler to lay the rest of the crap out differently. As I said, though, experience shows nothing like that happens. Dmitry. > > Jack >

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Barry Smith 04 Apr '11

04 Apr '11

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? Barry > > .c -> compiled with mpicc > .cxx -> compiled with mpicxx > > Is there something else missing? (Perhaps linking?) > > Sean

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Jack Poulson 04 Apr '11

04 Apr '11

On Mon, Apr 4, 2011 at 9:24 PM, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > > struct _p_Mat { > PETSCHEADER(struct _MatOps); > PetscLayout rmap,cmap; > ... > } > typedef struct _p_Mat *Mat; > Mat A; > Now ((PetscObject)A)->comm is kosher, because of the way C lays out the > struct. > I don't know whether C++ does the same (there is the issue of where it > sticks the vtable, and I'm not sure what else). > I imagine there will be no problem, since we've been compiling the PETSc C > code with C++ compilers for a decade now, > but I don't know whether the C++ standard guarantees that. Jed is the only > person I know that actually reads the standard > (or maybe it's part of the ABI). > > Dmitry. > I would think that most compilers would not even use a vtable for C code since there are no virtual functions and no class derivations. On the other hand, it is my understanding that the way vtables are handled is not in the standard and is up to the compiler. Jed may know better even though he hates C++. Jack

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Sean Farley 04 Apr '11

04 Apr '11

> > I don't know whether C++ does the same (there is the issue of where it > sticks the vtable, and I'm not sure what else). > I imagine there will be no problem, since we've been compiling the PETSc C > code with C++ compilers for a decade now, > but I don't know whether the C++ standard guarantees that. > Reading the wiki on C++0x, it seems that it is guaranteed following some guidelines: http://en.wikipedia.org/wiki/C%2B%2B0x#Modification_to_the_definition_of_pl… > Jed is the only person I know that actually reads the standard (or maybe > it's part of the ABI). > Heh, yeah. Jed will have to verify about the guidelines and what-not for sure. Sean

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Satish Balay 04 Apr '11

04 Apr '11

On Mon, 4 Apr 2011, Sean Farley wrote: > > > > configure.log ???? > > > > What about passing the compiler option -x C++? Or maybe you are already > > doing that but I would't know because you didn't send configure.log > > > > It's bad enough when our ignorant users don't send necessary > > configure.log files but you? > > > Fair enough :-) But this isn't a petsc-maint issue and configure.log usually > gets rejected because of its size. and yet you send it to petsc-dev [when you were supposed to send it to petsc-maint] - so its rejected. And I notice the configure.log was from a wrong build anyway.. > You could have tested the configure > option on your own since your $2000 laptop can compile the code in under 10 > minutes: We can't figure out what 'Using C/C++ linker: /opt/local/bin/mpicxx' is doing internally.. that part is in configure.log. Will have to figureout how to get atleast '-show' stuff into make.log satish > > https://twitter.com/shitbsmithsays > > You're almost right about the -x option but it's the other way around it > seems -x c (not a capital 'c'). > > Sean >

1 0

Re: [petsc-dev] Compiling C code with C compiler
by Sean Farley 04 Apr '11

04 Apr '11

> > 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? .c -> compiled with mpicc .cxx -> compiled with mpicxx Is there something else missing? (Perhaps linking?) Sean

1 0