Add conflict statement to sda as suggested

changed title from Add conflict statement as suggested to Add conflict statement to sda as suggested

added 1 commit

bd6b789b - Update spack.yaml to include sda

merged

mentioned in commit 57881f4a

Hi @thielblz, after merging there was the same error:

https://gitlab.ebrains.eu/technical-coordination/project-internal/devops/platform/ebrains-spack-builds/-/jobs/28764

==> Error: 'NoneType' object has no attribute 'rpartition'
==> Error: 'NoneType' object has no attribute 'rpartition'

I deleted depends_on('%gcc@9.4.0:') (it practically means the same as conflicts('%gcc@:9.3.999', when='@7.3.3d')) and the error was fixed, so this was probably a problem with the depends_on('%gcc') syntax.

However, the build was still not successful (unrelated with the previous error, I think):

https://gitlab.ebrains.eu/technical-coordination/project-internal/devops/platform/ebrains-spack-builds/-/jobs/28765

You can see the build logs here

I believe this is related to the old build base image — we still run CentOS7 there and this is based on glibc 2.17 — way older than the 2.22 introducing libmvec — so the library just isn't there (however, the configure flow of sda should probably check for the glibc version/existence of libmvec ;)). And we can't install a new libc via spack (or any other reasonable means for that matter ;) — so that's a point where the base image is just too old — and 8 years for a Linux Distribution is quite old, glibc@2.17 is even from 2012… @elmath

However, I'm still confused by the mentioned glibc versions 2.22 and 2.29… I don't understand why there are TWO versions mentioned, and even 2.22 would be way too young for CentOS 7 — is there some binary distributed in the software package that is linked somewhere else? @thielblz

linking sda_flex
/srv/test-build/spack/lib/spack/env/gcc/gfortran -Xlinker --enable-new-dtags -Xlinker -rpath -Xlinker '${ORIGIN}/../lib/' -g -O3 -W -Wall -Wno-target-lifetime -cpp -fPIC  -Wno-compare-reals -Wno-uninitialized -funroll-all-loops -finline-functions -Wtabs -Wunused-variable  -fopenmp -o ../bin/sda_flex csigfun.o mod_force_energy.o mod_set_parameters.o mod_compute_image_charge.o  mod_compute_metaldesolv.o mod_compute_force.o mod_compute_force_sdamm.o mod_compute_energy.o mod_compute_energy_sdamm.o mod_hydrodynamics.o mod_compute_analytic_2proteins.o mod_compute_analytic_sdamm.o mod_compute_energy_flex.o mod_init_position.o  utils.f90 read_input_file.f90 restart.f90 prepare_grid.f90 prepare_atom_protein.f90 solva.f90 make_exclusion_grid.f90 MainLoop_sda_2proteins.f90 MainLoop_sdamm.f90 MainLoop_sda_energy.f90 MainLoop_sda_pmf.f90 MainLoop_sda_2proteins_omp.f90 init_time.f90 compute_distance.f90 check_reaction_pair.f90 eschk.f90 change_conformation.f90 make_bd_move_2prot.f90 make_bd_move_2prot_timer_excl.f90 make_bd_move_sdamm.f90 bd_move.f90 check_exclusion.f90 main.f90 -Wl,-rpath=../lib -B ../lib -lsda -lstdc++
/srv/test-build/spack/var/spack/environments/release_v0_2_202112/.spack-env/view/bin/ld: warning: libmvec.so.1, needed by ../lib/libsda.so, not found (try using -rpath or -rpath-link)
/srv/test-build/spack/var/spack/environments/release_v0_2_202112/.spack-env/view/bin/ld: ../lib/libsda.so: undefined reference to `_ZGVbN2v_exp@GLIBC_2.22'
/srv/test-build/spack/var/spack/environments/release_v0_2_202112/.spack-env/view/bin/ld: ../lib/libsda.so: undefined reference to `log@GLIBC_2.29'
/srv/test-build/spack/var/spack/environments/release_v0_2_202112/.spack-env/view/bin/ld: ../lib/libsda.so: undefined reference to `exp@GLIBC_2.29'
/srv/test-build/spack/var/spack/environments/release_v0_2_202112/.spack-env/view/bin/ld: ../lib/libsda.so: undefined reference to `pow@GLIBC_2.29'
collect2: error: ld returned 1 exit status
make: *** [../bin/sda_flex] Error 1

This is odd. We also tried compiling sda on a cluster node which is running CentOS 7.6 and glibc 2.17 using gcc 10.2 (this was the most recent version available) and it worked just fine.

libmvec is not linked in the complied binary in this case. libmvec is only linked when compiling on a more recent system with glibc also at a newer version.

@thielblz I learned today that @elmath works on an update of the build image which will then match the runtime image (Ubuntu 20.04) — that's reasonable for many reasons — which might also help here.

Is there a possibility to get more "configure" or debug output in general from your build process? I could try to reproduce this on our local servers with support for container images for ASIC development — those run ancient CentOS too ;)…

The SDA build is a normal make compiling with gfortran and gcc. The make runs in the SDA/src directory. I think using

make clean
make -d

should give more information?

mentioned in issue #16 (closed)

mentioned in merge request !247 (merged)

mentioned in issue #37 (closed)

Add conflict statement to sda as suggested

Merge request reports

Activity