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