[petsc-dev] need c++ expert help

[Jed Brown]

"Smith, Barry F." <bsmith at mcs.anl.gov> writes:

>> On Dec 31, 2017, at 7:05 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>> 
>>>  I think it is just CXX.  The PCC business is the thing that magically changes from CC to CXX depending on --with-clanguage being set. But CXX is always the C++ linker.
>> 
>> That would make me happy, but in that case, let's get rid of PCC_LINKER,
>> SL_LINKER, DYNAMICLINKER, and LD_SHARED because they're all redundant.
>
>   I think they are absolutely needed in the legacy make system. 

If we need all these aliases to the same thing, they can go in
lib/petsc/conf/variables.  The generated petscvariables shouldn't have
all this redundancy.

>    Since the gnumake system seems to have worked flawlessly for a long time I have no problem removing the legacy make system. Is that what you are proposing?
>
>    Note you do have to have some mechanism to handle the --with-clanguage=cxx case 
>
>    Barry
>
>> 
>>>  Barry
>>> 
>>> 
>>>> On Dec 31, 2017, at 6:18 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>> 
>>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>>> 
>>>>> There is always a C++ linker available so long as PETSc was built without --with-cxx=0 so just use it, why make a big deal out of it?
>>>> 
>>>> What is it called?  I would like to just use CXX, but we have PCC_LINKER
>>>> written out independently.  I don't know any circumstance in which
>>>> PCC_LINKER is different from PCC, but maybe there is.  We should get rid
>>>> of this duplication unless there is a specific circumstance in which
>>>> they are different.
>>>> 
>>>> $ grep mpicxx ompi/lib/petsc/conf/petscvariables                                                                                                              
>>>> CXX = /home/jed/usr/ccache/ompi/bin/mpicxx                                                                                                                                                    
>>>> CXXCPP = /home/jed/usr/ccache/ompi/bin/mpicxx -E
>>>> 
>>>> $ grep mpicc ompi/lib/petsc/conf/petscvariables                                                                                                              
>>>> SL_LINKER = /home/jed/usr/ccache/ompi/bin/mpicc                                                                                                                                               
>>>> PCC = /home/jed/usr/ccache/ompi/bin/mpicc
>>>> PCC_LINKER = /home/jed/usr/ccache/ompi/bin/mpicc
>>>> CC = /home/jed/usr/ccache/ompi/bin/mpicc
>>>> DYNAMICLINKER = /home/jed/usr/ccache/ompi/bin/mpicc
>>>> CPP = /home/jed/usr/ccache/ompi/bin/mpicc -E
>>>> LD_SHARED = /home/jed/usr/ccache/ompi/bin/mpicc
>>>> 
>>>> 
>>>>>  Barry
>>>>> 
>>>>>> On Dec 31, 2017, at 5:58 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>>> 
>>>>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>>>>> 
>>>>>>>> On Dec 31, 2017, at 2:14 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>>>>> 
>>>>>>>> Matthew Knepley <knepley at gmail.com> writes:
>>>>>>>> 
>>>>>>>>> On Sun, Dec 31, 2017 at 2:35 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>>>>>> 
>>>>>>>>>> Matthew Knepley <knepley at gmail.com> writes:
>>>>>>>>>> 
>>>>>>>>>>> On Sun, Dec 31, 2017 at 1:55 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> These look like linker errors and that build uses
>>>>>>>>>>>> --with-cxxlib-autodetect=0.  We either need a rule to *link* C++ using
>>>>>>>>>>>> CXX (i.e., mpicxx) or add LIBS=-lstdc++.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I thought we were doing this (linking C++ mains with CXX).
>>>>>>>>>> 
>>>>>>>>>> After compiling to the object file (ex3.o) we don't know what language
>>>>>>>>>> main was written in, and this doesn't solve the actual problem that C++
>>>>>>>>>> linking is required if any object (not just main) depends on C++.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> My thinking here was the following:
>>>>>>>>> 
>>>>>>>>> 1) No C++ is allowed in PETSc, unless --with-clanguage=cxx, in which case
>>>>>>>>> the linker is C++
>>>>>>>>> 2) If C++ is in an external library, then that configure requires the C++
>>>>>>>>> library
>>>>>>>>> 3) The executable itself could be C++, in which case I proposed using the
>>>>>>>>> C++ linker explicitly
>>>>>>>>> 
>>>>>>>>> About not knowing which objects come with C++ main: I thought we did. Don't
>>>>>>>>> they go into a separate set?
>>>>>>>> 
>>>>>>>> Right, we do have that information for tests.  Note that a single test
>>>>>>>> executable can depend on multiple source files, and the one containing
>>>>>>>> main might not be C++ while another is.  I don't know if there are any
>>>>>>>> such instances in PETSc.
>>>>>>>> 
>>>>>>>> I can change the build rules for tests with C++ sources later today.
>>>>>>> 
>>>>>>> Jed, are you indicating that you will resolve the original problem I reported? Where will you resolve it? The problem may come up in one of my branches.
>>>>>> 
>>>>>> I was going to put it in a new branch from 'master'.  There is
>>>>>> disgusting duplication in 'maint' that has since been fixed so I'd
>>>>>> rather not do it there.
>>>>>> 
>>>>>> Under what conditions is PCC_LINKER different from CC (or CXX when
>>>>>> clanguage=C++)?  I need to find a C++ linker and would prefer to use
>>>>>> $(CXX) rather than adding a new configure test.  I feel like the
>>>>>> generated petscvariables has an inordinate amount of duplication all
>>>>>> with non-standard names and no documentation.
>>>>>> 
>>>>>> The cheap way to fix your issue is to add LIBS=-lstdc++ to your
>>>>>> configure.