https://bugzilla.redhat.com/show_bug.cgi?id=1474958
--- Comment #15 from Christoph Junghans <junghans(a)votca.org> ---
(In reply to Antonio Trande from comment #14)
(In reply to Christoph Junghans from comment #13)
> I saw that before for other mpi-enabled packages, if I recall correctly mock
> has no support for mpi and hence doesn't do a "module load
> mpi/openmpi-x86_64", which would prepend /usr/lib64/openmpi/lib to
> LD_LIBRARY_PATH (see module show "mpi/openmpi-x86_64") and fix the above
> issue. rpath aren't allowed for mpi packages either, so I am not sure how
> you want to fix.
>
> And setting CXX and friends won't change anything as mpicxx is internally
> just adding the same include paths and libraries to the flags:
> $ mpicxx --showme
> g++ -I/usr/include/openmpi-x86_64 -pthread -Wl,-rpath
> -Wl,/usr/lib64/openmpi/lib -Wl,--enable-new-dtags -L/usr/lib64/openmpi/lib
> -lmpi_cxx -lmpi
All MPI files are compiled with MPI compilers as required by the guidelines;
https://fedoraproject.org/wiki/Packaging:MPI doesn't list CC=mpicc as a must
item and it would also be a really bad idea in general, e.g. for codes, which
have mixed serial and parallel code. (Which isn't the case for LAMMPS though).
Sundials MPI libraries for example do not need to load any module in
Mock:
$ mock --no-clean -r fedora-rawhide-x86_64 --shell 'ldd
/usr/lib64/openmpi/lib/libsundials_nvecparallel.so.2'
Start: shell
linux-vdso.so.1 (0x00007fff9e309000)
libm.so.6 => /lib64/libm.so.6 (0x00007fa6b2969000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa6b274a000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fa6b251b000)
libklu.so.1 => /lib64/libklu.so.1 (0x00007fa6b22e6000)
libHYPRE.so.0.0 => /usr/lib64/openmpi/lib/libHYPRE.so.0.0
(0x00007fa6b1c62000)
libmpi.so.20 => /usr/lib64/openmpi/lib/libmpi.so.20 (0x00007fa6b195f000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa6b157a000)
/lib64/ld-linux-x86-64.so.2 (0x0000558ae39ba000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fa6b1376000)
libamd.so.2 => /lib64/libamd.so.2 (0x00007fa6b116a000)
libcolamd.so.2 => /lib64/libcolamd.so.2 (0x00007fa6b0f62000)
libbtf.so.1 => /lib64/libbtf.so.1 (0x00007fa6b0d5e000)
libsuitesparseconfig.so.4 => /lib64/libsuitesparseconfig.so.4
(0x00007fa6b0b59000)
libopenblas.so.0 => /lib64/libopenblas.so.0 (0x00007fa6ae77a000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa6ae3f2000)
libsuperlu.so.5.1 => /lib64/libsuperlu.so.5.1 (0x00007fa6ae17a000)
libmpi_cxx.so.20 => /usr/lib64/openmpi/lib/libmpi_cxx.so.20
(0x00007fa6adf5f000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa6add48000)
libopen-rte.so.20 => /usr/lib64/openmpi/lib/libopen-rte.so.20
(0x00007fa6adabc000)
libopen-pal.so.20 => /usr/lib64/openmpi/lib/libopen-pal.so.20
(0x00007fa6ad808000)
librt.so.1 => /lib64/librt.so.1 (0x00007fa6ad600000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fa6ad3fd000)
libhwloc.so.5 => /lib64/libhwloc.so.5 (0x00007fa6ad1c1000)
libgfortran.so.4 => /lib64/libgfortran.so.4 (0x00007fa6acde5000)
libsatlas.so.3 => /usr/lib64/atlas/libsatlas.so.3 (0x00007fa6abfea000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x00007fa6abddf000)
libltdl.so.7 => /lib64/libltdl.so.7 (0x00007fa6abbd5000)
libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007fa6ab995000)
Understand your doubts, so you can also ask any better clarification on
devel mailing list.
Ok, I got it.
$ objdump -x libsundials_nvecparallel.so.2 | grep R.*PATH
RUNPATH /usr/lib64/openmpi/lib
which comes from the "-Wl,-rpath -Wl,/usr/lib64/openmpi/lib
-Wl,--enable-new-dtags" in mpicxx, so reading
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...,
I am a bit unsure if only RPATH is contempt or RUNPATH as well.
Anyhow, we can get the same behavior as in sundials by adding
-DCMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING="%{__global_ldflags} -Wl,-rpath
-Wl,/usr/lib64/openmpi/lib -Wl,--enable-new-dtags". Is that ok with you?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component