[bugfix] Include config.h in lrutest.cc

This fixes a linker error for me. Without this patch I get:

rutest.cc:(.text._ZN3MPI9IntracommC2Ev[_ZN3MPI9IntracommC5Ev]+0x18): undefined reference to MPI::Comm::Comm()' /usr/bin/ld: CMakeFiles/lrutest.dir/lrutest.cc.o: in function MPI::Intracomm::Intracomm(ompi_communicator_t*)': lrutest.cc:(.text._ZN3MPI9IntracommC2EP19ompi_communicator_t[_ZN3MPI9IntracommC5EP19ompi_communicator_t]+0x2c): undefined reference to MPI::Comm::Comm()' /usr/bin/ld: CMakeFiles/lrutest.dir/lrutest.cc.o: in function MPI::Op::Init(void ()(void const, void*, int, MPI::Datatype const&), bool)': lrutest.cc:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x2a): undefined reference to ompi_mpi_cxx_op_intercept' /usr/bin/ld: CMakeFiles/lrutest.dir/lrutest.cc.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): undefined reference to MPI::Win::Free()' /usr/bin/ld: CMakeFiles/lrutest.dir/lrutest.cc.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): undefined reference to `MPI::Datatype::Free()'

I'm surprised that the CI did not catch this. The mentioned linker error shows up on ubuntu 23.10 with gcc 13.2.

Maybe this is some fallout of the recent changes to the build system. I'm not sure if my fix is correct or if this reveals some underlying problem. The missing #include "config.h" simply sticked out to me.

@simon.praetorius, @santiago.ospina Please have a look.

I think one should understand what's the problem here and why this was not found by the CI.

Maybe related: !1262 (merged), !1310 (merged).

Notice that this is also fixed by !1314 (merged). But since the latter maybe need some more discussion.

Thanks for the report!

I think that (up to !1314 (merged)) a dune .cc file without a config file has been ill formed because it does not include the necessary DUNE configuration options (e.g. #def HAVE_MPI 1 before !1310 (merged)). This is the nightmare of the config file: the user is always supposed to include it and understand what it contains, nonetheless, is was always super unclear how its being generated and where is supposed to be included. This was not explained anywhere until !1262 (merged) and this file is just an example of that lack of specification. That's also why we are pushing towards !1313 (merged), this way no one but the module maintainers need to be aware of these config files. So the fact that this ever "worked" is more concerning than the fact that we now get an explicit error.

edit: update link to !1313 (merged) instead of !1314 (merged).

I'm surprised that the CI did not catch this. The mentioned linker error shows up on ubuntu 23.10 with gcc 13.2.

Yep, this is a false positive, we do need to look into this!

assigned to @santiago.ospina

resolved all threads

mentioned in issue #357

merged

mentioned in commit 1293a8c2

mentioned in merge request !1314 (merged)

Ok, it is difficult for me to test on a local machine. I am trying to guess what the problem is and why adding the #include <config.h> fixed it:

• The old config.h includes not only defines like HAVE_XY but also workarounds for the a requirement that we have in dune: we need the C-bindings of MPI and not the C++-bindings
• If MPI is linked via add_dune_mpi_flags, for example, the flag -DHAVE_MPI=1 is passed to the compiler. Thus, for this flag we don't need to include any config.h file.
• Additionally, we need a bunch of preprocessor defines that modify the behavior of the mpi.h header, see also !943 (merged) and #211 (closed)
• With !1314 (merged) I propose to set the additional preprocessor defines only for dune files that chose to include dune/common/parallel/mpi.hh. If another library relies on the c++-bindings/headers whatever, then an include without these defines would be more appropriate. Not sure whether this works, though.

I would guess, that in ubuntu 23.04 the shipped mpi library is slightly different from the libraries shipped in older ubuntu version. Maybe some defaults are changed.

I will try to get a recent ubuntu in our docker registry so that we can test in the ci automatically