Difficulty linking the right version of GSL on Cosma with Intel 2020-update2
I'm not sure if this is a Swift bug but I think it's worth documenting here until we find a solution.
Using the new set of modules on Cosma recommended by Matthieu:
module purge
module load intel_comp/2020-update2
module load intel_mpi/2020-update2
module load ucx/1.8.1
module load parmetis/4.0.3-64bit
module load parallel_hdf5/1.10.6
module load fftw/3.3.8cosma7
module load gsl/2.5
./configure \
--with-gravity=basic \
--enable-ipo \
--enable-debug \
--with-hdf5 \
--with-fftw \
--with-parmetis \
--with-gsl
Results in a swift executable that is wrongly linked to /lib64/libgsl.so:
[jch@login7c build]$ ldd examples/swift
linux-vdso.so.1 => (0x00007fff9c2b0000)
libhdf5_hl.so.10 => /cosma/local/hdf5/gnu_7.3.0/1.8.20/lib/libhdf5_hl.so.10 (0x00002b07767b7000)
libhdf5.so.10 => /cosma/local/hdf5/gnu_7.3.0/1.8.20/lib/libhdf5.so.10 (0x00002b07769d9000)
libz.so.1 => /lib64/libz.so.1 (0x00002b0776ec7000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b07770dd000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x00002b07772e1000)
libgsl.so.0 => /lib64/libgsl.so.0 (0x00002b07774ed000)
libgslcblas.so.0 => /lib64/libgslcblas.so.0 (0x00002b0777916000)
libm.so.6 => /lib64/libm.so.6 (0x00002b0777b53000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00002b0777e55000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b077807b000)
libc.so.6 => /lib64/libc.so.6 (0x00002b0778297000)
/lib64/ld-linux-x86-64.so.2 (0x00002b0776593000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b0778665000)
libsatlas.so.3 => /usr/lib64/atlas/libsatlas.so.3 (0x00002b077887b000)
libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00002b07794c8000)
libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00002b07797ea000)
If I don't load the GSL module and instead use --with-gsl=/cosma/local/gsl/2.5/ then I get the same (wrong) result.
Note that it picks up libgsl.so.0 - this is the version in /lib64/. The one the module points at is libgsl.so.23. I think (although I'm not certain) that means it's not a problem with the runtime search path. It seems to have picked the wrong library version when the program was linked, so this can't be fixed with LD_LIBRARY_PATH or --rpath flags.
If I use the Intel 2018 set of modules, it finds the right GSL. So to check whether this is a problem with the modules, I did a minimal swift build with NO modules loaded and using /usr/bin/gcc as the compiler:
module purge
./configure \
--disable-mpi \
--with-hdf5=/cosma/local/hdf5/gnu_7.3.0/1.8.20/bin/h5cc \
--with-gsl=/cosma/local/gsl/2.5/
I still get the wrong GSL:
[jch@login7c build]$ ldd examples/swift
linux-vdso.so.1 => (0x00007ffca29e2000)
libhdf5_hl.so.10 => /cosma/local/hdf5/gnu_7.3.0/1.8.20/lib/libhdf5_hl.so.10 (0x00002aeabce7e000)
libhdf5.so.10 => /cosma/local/hdf5/gnu_7.3.0/1.8.20/lib/libhdf5.so.10 (0x00002aeabd0a0000)
libz.so.1 => /lib64/libz.so.1 (0x00002aeabd58e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002aeabd7a4000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x00002aeabd9a8000)
libgsl.so.0 => /lib64/libgsl.so.0 (0x00002aeabdbb4000)
libgslcblas.so.0 => /lib64/libgslcblas.so.0 (0x00002aeabdfdd000)
libm.so.6 => /lib64/libm.so.6 (0x00002aeabe21a000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00002aeabe51c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aeabe742000)
libc.so.6 => /lib64/libc.so.6 (0x00002aeabe95e000)
/lib64/ld-linux-x86-64.so.2 (0x00002aeabcc5a000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aeabed2c000)
libsatlas.so.3 => /usr/lib64/atlas/libsatlas.so.3 (0x00002aeabef42000)
libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00002aeabfb8f000)
libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00002aeabfeb1000)
But maybe I've done something else wrong in this case?