Hi,
Am Wed, Mar 30, 2022 at 09:45:30AM +0200 schrieb Markus Blatt:
Am Tue, Mar 29, 2022 at 09:28:22PM +0200 schrieb Graham Inggs:
It seems opm-simulators FTBFS in much the same way now after
opm-common has been rebuilt.
I will take a look and try to fix it. It seems there is a reference to
libpython3.9.so.
I think I figured out what the issue is. The cmake configuration files of all
opm modules
have an explicit list of libraries that need to be linked with the library of
the module and
this is always used for linking. This list is only updated if the
module/package is rebuilt.
All modules built before the transition have a reference to
/usr/lib/x86_64-linux-gnu/libpython3.9.so which was in the Cmake configuration file of opm-common
when they where built. The only way to get rid of them seems to be rebuilding
all. Hence one
would need to change the dependencies along the following lines
dependency level 3: opm-grid, opm-material,
dependency level 4: opm-models, opm-uscaling
dependency level 5: opm-simulators (currently level 3)
Note that opm-upscaling is only needed because: if a user searches for it in
its project,
then compilation will fail in the same manner as opm-simulators is failing
currently.
Explanation why it is the way it is:
It is the way OPM uses CMake, these scripts date back to an old Cmake version
(without support
for targets). At that time this approach was (or seemed to be) needed for
static libraries. Otherwise
there would have been linker errors, because we use embedded python in
opm-common. Updating to modern
CMake targets would have prevented this issue.
Sorry for the trouble and HTH.
Cheers,
Markus
