cmake, make, sowing and utilities that are not libraries that go into the overall simulation are not compiled with mpicxx etc.
> On Aug 22, 2019, at 1:03 AM, Pierre Jolivet via petsc-dev > <petsc-dev@mcs.anl.gov> wrote: > > > >> On 22 Aug 2019, at 7:42 AM, Balay, Satish <ba...@mcs.anl.gov> wrote: >> >> On Thu, 22 Aug 2019, Pierre Jolivet via petsc-dev wrote: >> >>> Hello, >>> PETSc is linking “sequential” libraries with MPI libraries. >>> $ otool -L libmetis.dylib >>> /usr/local/opt/mpich/lib/libmpi.12.dylib (compatibility version 14.0.0, >>> current version 14.7.0) >>> $ otool -L libfftw3.dylib >>> /usr/local/opt/mpich/lib/libmpi.12.dylib (compatibility version 14.0.0, >>> current version 14.7.0) >> >> this will occur if one uses mpi compilers to build PETSc. > > Why, though? > If MPICXX_SHOW != “Unavailable”, is it mandatory to force CXX=MPICXX in Metis > CMake? > Wouldn’t it be possible to just extract the compiler binary name and use that > as CXX? > I understand you don’t want to either overcomplicate things or fix something > that is not broken — for you — so I’m just making sure that it would be OK if > I patch this like that locally. > >>> Is there anyway to avoid this, by using a “sequential” compiler and/or >>> linker? >> >> Yes - you can build these (sequential) packages/petsc with --with-mpi=0 [and >> without mpi compilers] >> >>> I’m asking because we use PETSc libraries to compile both parallel and >>> sequential wrappers. >>> Our Metis wrapper is marked as a sequential one, but since you are linking >>> libmetis with MPI, this is problematic for some configurations. >> >> Not sure what What mean by 'wrappers' here - esp 'Metis wrapper'. Its >> just a library. > > It’s just another dynamic library compiled on top of libmetis that is then > dynamically loaded by a DSL, which may or may not be launched with MPIRUN. > >> If you are using petsc build tools to install these packages for a >> different use [other than the petsc usage specified by configure] - >> use different petsc builds as indicated above for different packages - >> as needed. > > Having to configure + build PETSc with both real and complex numbers is > already long enough. > That would mean a 3rd build, but why not. > Are there some guarantees that CXX with --with-mpi=0 will be the same as the > underlying compiler of MPICXX? (I’m thinking of incompatible libc++ that > would make it impossible to link in the same library Metis and the later one > compiled PETSc with --with-mpi=1) This can be tricky. If you using --download-mpich then you know they are compatible since the MPI is built from the sequential, but if you are only given mpicc you have to be careful how you pull out the parts, You can start with -show which works for some of them. OpenMPI has several options to get info about exactly what it uses for flags etc. Instead of hacking PETSc I would recommending having simple scripts that use PETSc configure in the way I described in my previous email Barry > > Thanks, > Pierre > >> BTW: Current petsc configure/builder builds only parallel fftw. [it does not >> support building sequential fftw. But I guess this could be added] >> >> Satish >
