Jed I have merge https://bitbucket.org/petsc/petsc/commits/branch/jed/tests-cxx-linker into barry/more-to-new-test-harness on crank using the /sandbox/petsc/petsc.next-2 with arch-linux-gcc-ifc-cmplx which is where the compile/link problem appeared. The error no longer appears and thus appears to compile/link the example correctly.
There were some conflicts with the merge in examples I didn't bother to deal with in the test. So what to do? Do I do the merge of jed/tests-cxx-linker into barry/more-to-new-test-harness properly and then merge into next and hope it breaks nothing on any machine tonight? Barry > On Jan 1, 2018, at 1:13 PM, Jed Brown <[email protected]> wrote: > > Jed Brown <[email protected]> writes: > >> 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. > > The Python is just damn convoluted, but I was able to implement this by > deleting code. > > https://bitbucket.org/petsc/petsc/commits/branch/jed/tests-cxx-linker > > Barry, can you try this in whatever branch is giving you issues?
