Open MakisH opened 6 months ago
I am now trying together with @fujikawas to debug this.
I get the same error on two systems:
@fujikawas cannot reproduce it (Ubuntu 22.04).
We both use DUNE 2.9.1.
I was able to build the dune-elastodynamics module with DUNE 2.8 (also dune-common 2.8).
Hello together, I have to admit that I didn't really touched this quite some time :sweat_smile: (I guess this is the problem with single person codes ...) ... fell free to ask if you need any help.
@IshaanDesai @MakisH @Fujikawas I tried to build with the most recent dune module versions on Ubuntu 20.04 and I'm able to build without errors (I'm currently not able to test on Ubuntu 22.04).
These are the steps I am currently using: https://github.com/precice/vm/blob/0854655ff70da6d76197cf2a499f3decbdf6ba98/provisioning/install-dune.sh
I found the trigger and the fix, but I don't understand them.
It looks like, as I was reorganizing my script, I removed the dune-grid
module. This was, however, cloned automatically by some other module, in the branch release/2.9
.
I now explicitly added it again, from the v2.9.1
tag, and it seems to work.
This should have complained in a different way earlier on.
I was also looking at the wrong direction for a while, as the error was about Dune::UGGrid
, but the guilty file was not from dune-uggrid
, but dune-grid
.
Thank you all for your help!
It looks like the order of building modules was somehow important (we still don't understand why). Building DUNE first, DuMuX then, helped. Building DuMuX first, DUNE then, was complaining with the same issue.
Hi, I currently have two suspicions as to why the restructuring and module order mattered. 1) Building a module and then installing a suggested dependency may lead to problems where the dependent module is using cached information about the availability of the added dependency. 2) You were/are building modules with different CMake options which may be fine but may cause issues. In particular the cmake.opts from DuMux configures the modules to build shared libraries, might be related to your linking error. If possible I would suggest using one set of CMake options and building all modules together at the end.
Is DuMuX flexible enough to use the default CMake options of DUNE, or are there any particular restrictions?
Building DuMux with the default CMake options of DUNE will work. The cmake.opts
of DuMux mainly set some compiler flags and enable Python bindings and building shared libraries for the modules. The compiler options are not necessary and as far as I am aware you don't use the Python bindings of DUNE/DuMux. Building shared libraries is also practical, but not necessary
As I am trying to install both the DuMuX and the DUNE adapters in the VM, using the same DUNE installation, I realized that this module does not work at the moment with DUNE 2.9 (probably that is the reason):
build-dune-elastodynamics.log