"Smith, Barry F." <[email protected]> writes: >> On Dec 31, 2017, at 7:05 PM, Jed Brown <[email protected]> wrote: >> >> "Smith, Barry F." <[email protected]> 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 <[email protected]> wrote: >>>> >>>> "Smith, Barry F." <[email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>> "Smith, Barry F." <[email protected]> writes: >>>>>> >>>>>>>> On Dec 31, 2017, at 2:14 PM, Jed Brown <[email protected]> wrote: >>>>>>>> >>>>>>>> Matthew Knepley <[email protected]> writes: >>>>>>>> >>>>>>>>> On Sun, Dec 31, 2017 at 2:35 PM, Jed Brown <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Matthew Knepley <[email protected]> writes: >>>>>>>>>> >>>>>>>>>>> On Sun, Dec 31, 2017 at 1:55 PM, Jed Brown <[email protected]> >>>>>>>>>>> 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.
