On Sun, Dec 31, 2017 at 3: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. > True. I think we just have to have a policy against that. > I can change the build rules for tests with C++ sources later today. > Cool. Thanks, Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
