Cannot find mpi.h on compile

[sauergeek]

Bug Report

teuchos @bartlettroscoe This is probably more general than just teuchos; it's just the first place the compilation fails.

Description

[ 1%] Building CXX object packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o /var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/core/src/Teuchos_GlobalMPISession.cpp:49:12: fatal error: mpi.h: No such file or directory 49 | # include "mpi.h" ... % ls -ald /usr/include/mpich-x86_64/mpi.h -rw-r--r--. 1 root root 140861 Dec 9 2021 /usr/include/mpich-x86_64/mpi.h

Steps to Reproduce

1. SHA1: (I have no idea what this is)

2. Configure script: mkdir trilinos setenv CPPFLAGS "-I/usr/include/mpich-x86_64 -I/usr/sup/include -I/usr/include" setenv LDFLAGS "-L/usr/lib64/mpich/lib -L/usr/sup/lib64 -L/usr/sup/lib -L/usr/lib64" cmake -DTrilinos_ENABLE_ALL_PACKAGES=ON \ -DTPL_ENABLE_MPI=ON \ -DMPI_BASE_DIR=/usr/lib64/mpich \ -DMPI_INC=/usr/include/mpich-x86_64 \ -DMPI_INCDIR=/usr/include/mpich-x86_64 \ -DMPI_INCDIRS=/usr/include/mpich-x86_64 \ -DMPI_INCPATH=/usr/include/mpich-x86_64 \ -DMPI_INCLUDE_DIR=/usr/include/mpich-x86_64 \ -DMPI_INCLUDE_DIRS=/usr/include/mpich-x86_64 \ -DMPI_INCLUDE_PATH=/usr/include/mpich-x86_64 \ -DMPI_INC_DIR=/usr/include/mpich-x86_64 \ -DMPI_INC_DIRS=/usr/include/mpich-x86_64 \ -DMPI_INC_PATH=/usr/include/mpich-x86_64 \ -DMPI_LIB_PATH=/usr/lib64/mpich/lib \ -DBUILD_SHARED_LIBS='TRUE' \ -DCMAKE_SYSTEM_PREFIX_PATH=/usr/sup/gcc-11.2.0:/usr/sup \ -DCMAKE_SYSTEM_PROGRAM_PATH=/usr/sup/gcc-11.2.0/bin:/usr/sup/bin \ -DCMAKE_SYSTEM_LIBRARY_PATH=/usr/sup/gcc-11.2.0/lib64:/usr/sup/11.2.0/lib:/usr/sup/lib64:/usr/sup/lib \ -DCMAKE_SYSTEM_INCLUDE_PATH=/usr/sup/gcc-11.2.0/include:/usr/sup/include \ -DCMAKE_C_COMPILER=/usr/sup/gcc-11.2.0/bin/gcc \ -DCMAKE_CXX_COMPILER=/usr/sup/gcc-11.2.0/bin/g++ \ -DCMAKE_Fortran_COMPILER=/usr/sup/gcc-11.2.0/bin/gfortran \ -DCMAKE_INSTALL_PREFIX=/usr/sup/trilinos-release-14-2-0 \ ..

3. Configure log: cmake-out.txt

4. Build log: [attach here] % make [ 0%] Building CXX object commonTools/gtest/CMakeFiles/gtest.dir/gtest/gtest-all.cc.o [ 1%] Linking CXX shared library libgtest.so [ 1%] Built target gtest [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_CPUDiscovery.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_Command_Line_Parsing.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_Core.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_Error.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_ExecPolicy.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_HostBarrier.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_HostSpace.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_HostSpace_deepcopy.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_HostThreadTeam.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_MemoryPool.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_MemorySpace.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_Profiling.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_SharedAlloc.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_Spinwait.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_Stacktrace.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_hwloc.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/Serial/Kokkos_Serial.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/Serial/Kokkos_Serial_Task.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir///tpls/desul/src/Lock_Array_CUDA.cpp.o [ 1%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir///tpls/desul/src/Lock_Array_HIP.cpp.o [ 1%] Linking CXX shared library libkokkoscore.so [ 1%] Built target kokkoscore [ 1%] Building CXX object packages/kokkos/containers/src/CMakeFiles/kokkoscontainers.dir/impl/Kokkos_UnorderedMap_impl.cpp.o [ 1%] Linking CXX shared library libkokkoscontainers.so [ 1%] Built target kokkoscontainers [ 1%] Building CXX object packages/kokkos/algorithms/src/CMakeFiles/kokkosalgorithms.dir/KokkosAlgorithms_dummy.cpp.o [ 1%] Linking CXX shared library libkokkosalgorithms.so [ 1%] Built target kokkosalgorithms [ 1%] Building CXX object packages/kokkos/simd/src/CMakeFiles/kokkossimd.dir/Kokkos_SIMD_dummy.cpp.o [ 1%] Linking CXX shared library libkokkossimd.so [ 1%] Built target kokkossimd [ 1%] Building CXX object packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_ArrayView.cpp.o [ 1%] Building CXX object packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_CWrapperSupport.cpp.o [ 1%] Building CXX object packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_CommandLineProcessor.cpp.o [ 1%] Building CXX object packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_Describable.cpp.o [ 1%] Building CXX object packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_Details_Allocator.cpp.o [ 1%] Building CXX object packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o /var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/core/src/Teuchos_GlobalMPISession.cpp:49:12: fatal error: mpi.h: No such file or directory 49 | # include "mpi.h" | ^~~ compilation terminated. make[2]: [packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/build.make:146: packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o] Error 1 make[1]: [CMakeFiles/Makefile2:8623: packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/all] Error 2 make: *** [Makefile:166: all] Error 2

5. Input deck: (n/a)

6. Do this. (n/a)

7. Do that. (n/a)

8. Shake fist angrily at computer. This one happened repeatedly as I tried to extract more and more variables to feed CMake, for the sole purpose of telling it that the MPI include files are in /usr/include/mpich-x86_64. Also a great deal of swearing at and about CMake for not obeying basic environment variables like CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH, and PATH.

9. Run log: (n/a)

[sauergeek]

My systems have two different MPI implementations available: mpich and openmpi. I can use either one -- assuming I can get Trilinos to find the mpi.h for either one. CMake is is uniquely awful at being able to find files, which it wants, that are in unusual places.

[sauergeek]

The OS involved is RHEL 8. Both openmpi and mpich are provided by RHEL; I have merely installed them. The weird /usr/include subpath is all RHEL.

[bartlettroscoe]

@sauergeek, this is usually due to a configure problem.

Ccan you please attach the full stdout+strerr for the following commands:

$ cmake [all of your options] &> configure.out

$ cd packages/teuchos/core/src
$ make VERBOSE=1 Teuchos_GlobalMPISession.cpp.o &> make.out

?

[sauergeek]

configure.out, as attached in step 3 above as cmake-out.txt.

% cd packages/teuchos/core/src % make VERBOSE=1 Teuchos_GlobalMPISession.cpp.o >& make.out % cat !$ cat make.out cd /var/tmp/Trilinos-trilinos-release-14-2-0/trilinos && make -f packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/build.make packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o make[1]: Entering directory '/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos' Building CXX object packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o cd /var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/teuchos/core/src && /usr/sup/gcc-11.2.0/bin/g++ -DKOKKOS_DEPENDENCE -DTEUCHOSCORE_LIB_EXPORTS_MODE -Dteuchoscore_EXPORTS -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/teuchos/core/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/core/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/kokkos/core/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/kokkos/core/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/kokkos -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/kokkos/core/src/../../tpls/desul/include -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/kokkos/containers/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/kokkos/containers/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/kokkos/algorithms/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/kokkos/algorithms/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/kokkos/simd/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/kokkos/simd/src -O3 -DNDEBUG -std=c++17 -fPIC -MD -MT packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o -MF CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o.d -o CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o -c /var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/core/src/Teuchos_GlobalMPISession.cpp /var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/core/src/Teuchos_GlobalMPISession.cpp:49:12: fatal error: mpi.h: No such file or directory 49 | # include "mpi.h" | ^~~ compilation terminated. make[1]: [packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/build.make:146: packages/teuchos/core/src/CMakeFiles/teuchoscore.dir/Teuchos_GlobalMPISession.cpp.o] Error 1 make[1]: Leaving directory '/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos' make: [Makefile:333: Teuchos_GlobalMPISession.cpp.o] Error 2

I note that none of the things I tried to bring in as additional include directories appear on this command line.

[bartlettroscoe]

The problem is that this is not using the MPI compiler wrapper. Instead, it is using the raw compiler:

/usr/sup/gcc-11.2.0/bin/g++ 

Plese change these configure options:

-DCMAKE_C_COMPILER=/usr/sup/gcc-11.2.0/bin/gcc
-DCMAKE_CXX_COMPILER=/usr/sup/gcc-11.2.0/bin/g++
-DCMAKE_Fortran_COMPILER=/usr/sup/gcc-11.2.0/bin/gfortran

to:

-DCMAKE_C_COMPILER=$(which mpicc)
-DCMAKE_CXX_COMPILER=$(which mpic++)
-DCMAKE_Fortran_COMPILER=$(which mpif90)

That will usually do the job.

[sauergeek]

Interesting. Trying that now. I'd gone with those explicit settings because when I ran cmake without them, it had picked up /bin/gcc etc. of its own, and I'd much rather it use the newer build of gcc I have elsewhere. (That, and also swearing at cmake for not obeying PATH.)

[sauergeek]

It got past the place where it was initially failing. I'll let the build continue and report back on whether it trips over the same issue elsewhere.

[bartlettroscoe]

Interesting. Trying that now. I'd gone with those explicit settings because when I ran cmake without them, it had picked up /bin/gcc etc. of its own, and I'd much rather it use the newer build of gcc I have elsewhere. (That, and also swearing at cmake for not obeying PATH.)

@sauergeek, consult the MPI documentation on using newer compilers, but my experience is that you really need to use the same compiler version that was used to build that MPI. So if you want a newer compiler, that usually means building and installing MPI again with that compiler. If you have a different experience, please let me know.

These days a lot of people are using Spack to build and install MPI:

• https://spack.io/

[sauergeek]

I found another missing dependency -- krino couldn't find gtest.h -- which I was able to straightforwardly fix by installing gtest-devel. It's odd that cmake didn't notice it missing, though. And unfortunately then my session crashed, so I didn't get to see past about 75% built. I will try another build tomorrow.

[sauergeek]

I have what looks to be an internal error, possibly from a too-long command line. The error:

[ 75%] Building CXX object packages/krino/krino/unit_tests/CMakeFiles/krino_unit.dir/Akri_Unit_main.cpp.o /var/tmp/Trilinos-trilinos-release-14-2-0/packages/krino/krino/unit_tests/Akri_Unit_main.cpp:12:10: fatal error: stk_unit_test_utils/ParallelGtestOutput.hpp: No such file or directory 12 | #include <stk_unit_test_utils/ParallelGtestOutput.hpp> | ^~~~~~~~~~~~~ compilation terminated. make[2]: [packages/krino/krino/unit_tests/CMakeFiles/krino_unit.dir/build.make:482: packages/krino/krino/unit_tests/CMakeFiles/krino_unit.dir/Akri_Unit_main.cpp.o] Error 1 make[1]: [CMakeFiles/Makefile2:19001: packages/krino/krino/unit_tests/CMakeFiles/krino_unit.dir/all] Error 2 make: *** [Makefile:166: all] Error 2

That file exists, in the source tree:

packages/stk/stk_unit_test_utils/stk_unit_test_utils/ParallelGtestOutput.hpp

But 'stk_unit_test_utils' does not appear in the huge string of -I flags in the command generated by make. Following the pattern of the test command you gave me earlier:

% cd packages/krino/krino/unit_tests/ % make VERBOSE=1 Akri_Unit_main.cpp.o >& make.out make-out.txt

When I added the missing -I flag by hand and ran the command, it worked, but the subsequent link step failed with several thousand undefined reference errors, which suggests a missing -L or more likely -l flag somewhere. Alternately, it may be that ParallelGtestOutput.hpp should be #ifdefed out. Either way, as this is in krino, I think I need to now invoke @drnobleabq . link-out.txt

I am attempting to build the latest release of Trilinos, version 14.2.0, from source on RHEL 8.

[sauergeek]

As @drnobleabq never responded, I tried simply removing Krino from the build. The build got further, but then failed on mpi.h in Teuchos again. As Teuchos seems to be critical for Trilinos to work, I can't remove it, so instead I get to fight with it some more. The first problem I encountered was trilinos/packages/PyTrilinos/src/gen_teuchos_rcp.py failing to be able to find mpi.h. I was surprised that a Python script wanted a C include file. When I investigated, I found the following faulty assumption:

def get_mpi_version(): header = os.path.join(MPI_BASE_DIR, "include/mpi.h") version = "" for line in open(header, 'r').readlines(): if "MPI_VERSION" in line: version = line.split()[2] break return version

Red Hat's MPI_BASE_DIR is /usr/lib64/mpich, so this bit of code concludes -- wrongly -- that mpi.h is /usr/lib64/mpich/include/mpi.h. In reality, it's /usr/include/mpich-x86_64/mpi.h. Which, admittedly, is weird, but that's how Red Hat organized its MPI distribution. I got around this by replacing the header assignment:

def get_mpi_version(): header = "/usr/include/mpich-x86_64/mpi.h" version = "" for line in open(header, 'r').readlines(): if "MPI_VERSION" in line: version = line.split()[2] break return version

That's all fine, until I get to an invocation of swig, also still in Teuchos. That invocation is missing a surprising number of -I flags. The one invoked by the original build:

/usr/sup/bin/swig -python -doxygen -relativeimport -py3 -outdir PyTrilinos/Teuchos -c++ -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/PyTrilinos/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/PyTrilinos/src -I/usr/sup/Python-3.9.2/include/python3.9 -I/usr/sup/Python-3.9.2/lib/python3.9/site-packages/numpy/core/include -o /var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/PyTrilinos/src/Teuchos.RCPPYTHON_wrap.cpp /var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/PyTrilinos/src/Teuchos.RCP.i

That produces 100+ "Unable to find" errors for various %include invocations. I found every directory needed, resulting in a much longer string of -I flags:

/usr/sup/bin/swig -python -doxygen -relativeimport -py3 -outdir PyTrilinos/Teuchos -c++ -I/usr/sup/Python-3.9.2/include/python3.9 -I/usr/sup/Python-3.9.2/lib/python3.9/site-packages/numpy/core/include -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/PyTrilinos/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/anasazi/epetra/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/anasazi/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/domi/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/epetra/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/epetraext/src/model_evaluator -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/ifpack/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/isorropia/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/isorropia/src/epetra -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/ml/src/MLAPI -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/ml/src/Utils -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/nox/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/nox/src-epetra -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/nox/src-loca/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/nox/src-loca/src-epetra -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/comm/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/core/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/numerics/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/parameterlist/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/packages/tpetra/core/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/PyTrilinos/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/anasazi/epetra/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/epetra/src -I/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/tpetra/core/src -o /var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/PyTrilinos/src/Teuchos.RCPPYTHON_wrap.cpp /var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/PyTrilinos/src/Teuchos.RCP.i

But when I run that swig command by hand, it now produces:

/var/tmp/Trilinos-trilinos-release-14-2-0/packages/teuchos/parameterlist/src/Teuchos_ParameterList.hpp:319: Error: Syntax error in input(3).

The offending line is:

template <typename U, typename = std::enable_if_t<std::is_same_v<std::decay_t<U>, ParameterEntry>>>

...and I don't speak C++ at all, so I have no idea how to fix it.

[bartlettroscoe]

@sauergeek, I don't know how to advise on PyTrilinos issues. Unless you really need that package, I would suggest disabling PyTrilinos with -D Trilinos_ENABLE_PyTrilinos=OFF.

@trilinos/pytrilinos

[bartlettroscoe]

CC: @trilinos/framework, @sebrowne

[sauergeek]

Trying a build without PyTrilinos; I'll report back tomorrow how it fared.

[sauergeek]

That build succeeded. I'm now trying with tests enabled. (I'd added "-DTrilinosInstallTests_ENABLE_TESTS='FALSE'" to try to get around the gtest issues I was seeing in krino, but to no effect.) With luck, not only will this build succeed, it'll also pass all of its tests.

[sauergeek]

That build also succeeded, but every subsequent step fails.

% make test Running tests... Test project /var/tmp/Trilinos-trilinos-release-14-2-0/trilinos No tests were found!!!

That's the best failure of them. The others (make check and make install) re-run cmake -- something that should never happen -- and then fail. They initially fail for lack of a top-level README file. (Why does cmake care that a README exists?). If I create the README, it then fails for lack of a top-level LICENSE file. (Why does cmake care that a LICENSE exists?) They then diverge. make check produces a long-form error similar to make test:

% make check ...lots of configuration gorp removed... UpdateCTestConfiguration from :/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/kokkos-kernels/DartConfiguration.tcl UpdateCTestConfiguration from :/var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/kokkos-kernels/DartConfiguration.tcl Test project /var/tmp/Trilinos-trilinos-release-14-2-0/trilinos/packages/kokkos-kernels Constructing a list of tests Done constructing a list of tests Updating test list for fixtures Added 0 tests to meet fixture requirements Checking test dependency graph... Checking test dependency graph end No tests were found!!! Built target check

make install rebuilds some stuff, likely due to the unnecessary (and likely damaging) re-run of cmake, and then actually installs where I told it to.

I am not at all confident that this build will work. The test suite failed for lack of tests to run. But, as this entire operation was to build a dependency for Xyce, I'll now swear a lot at Xyce instead. I may be back, depending on whether Xyce blames Trilinos for something.

[bartlettroscoe]

Tests are not enabled by default. You have to enable them with:

-D Trilinos_ENABLE_TESTS=ON

See:

• https://docs.trilinos.org/files/TrilinosBuildReference.html#enable-or-disable-tests-for-specific-packages

make install rebuilds some stuff, likely due to the unnecessary (and likely damaging) re-run of cmake, and then actually installs where I told it to.

What version of CMake are you using?

[sauergeek]

% cmake -version cmake version 3.26.4

CMake suite maintained and supported by Kitware (kitware.com/cmake).

[sauergeek]

I will try another build with the tests enabled, but I won't have a report back on that until the Monday after next -- I'm out next week.

[bartlettroscoe]

cmake version 3.26.4

That is a very current version of CMake. There was a defect in older Cmake versions that could trigger an unnecessary rebuild.

There may be a bug in one of the CMakeLists.txt files in Trilinos. When using the Ninja generator and build tool, it is possible to debug what is triggering these rebuilds. (But I have not seen this in some time.)

[sauergeek]

With tests enabled, I'm once again back to what looks like at least one bug in the code itself:

In file included from /var/tmp/Trilinos-trilinos-release-14-2-0/packages/seacas/libraries/ioss/src/exodus/Ioex_DecompositionData.h:25, from /var/tmp/Trilinos-trilinos-release-14-2-0/packages/seacas/libraries/ioss/src/exodus/Ioex_DecompositionData.C:8: /var/tmp/Trilinos-trilinos-release-14-2-0/packages/seacas/libraries/ioss/src/Ioss_Decomposition.h: In member function âvoid Ioss::Decomposition<INT>::communicate_element_data(T*, T*, size_t) constâ: /var/tmp/Trilinos-trilinos-release-14-2-0/packages/seacas/libraries/ioss/src/Ioss_Decomposition.h:295:15: error: âMY_Alltoallvâ is not a member of âIossâ 295 | Ioss::MY_Alltoallv(export_data, exportElementCount, exportElementIndex, import_data, | ^~~~~~~~~~~~

Seven more of identical complaint, and the build errors out.

[bartlettroscoe]

@trilinos/seacas, see above IOSS errors.

[gsjaardema]

If I remember correctly, there was a possible inconsistency in the parallel defines that looks like what is happening here. There is a SEACAS_HAS_MPI define and a PARALLEL_AWARE_EXODUS define which should typically both be the same setting. It looks like your build might have SEACAS_HAS_MPI=FALSE and PARALLEL_AWARE_EXODUS=TRUE or something similar to this... This would cause some parallel code to be enabled, but some to be disabled which is consistent with what you are seeing...

[bartlettroscoe]

@gsjaardema, is this a case where a configure-time assert in the CMakeLists.txt file might be able to catch something like this

If I remember correctly, there was a possible inconsistency in the parallel defines that looks like what is happening here. There is a SEACAS_HAS_MPI define and a PARALLEL_AWARE_EXODUS define which should typically both be the same setting. It looks like your build might have SEACAS_HAS_MPI=FALSE and PARALLEL_AWARE_EXODUS=TRUE or something similar to this... This would cause some parallel code to be enabled, but some to be disabled which is consistent with what you are seeing...

@gsjaardema, would it be possible to put in a configure-time assert in a CMakeLists.txt file to catch something like this and report it to the user with a more targeted error message?

[gsjaardema]

I think that the symbols were actually consolidated such that it was no longer possible to get into this situation. I think this was fixed after the 14.2 release which I think is what is being used here. I will see if I can recreate what caused that situation...

[github-actions[bot]]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label. If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE. If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.