Why the command in singularity container can not be run? - singularity-container

In my project, i use singularity to build a mpi.sif.
I have a openMPI in my host file system. I do not want to install mpi in the container.
so i try to copy the mpi files to container.
Some content of the define mpi.def is like :
[stack#node01 pitzDaily]$ cat mpi.def
Bootstrap: docker
From: centos:7
%help
This recipe provides an OpenFOAM-7 environment installed
with GCC and OpenMPI-4.
%labels
Author stack
%files from stage_name
/share/apps/openmpi/intel/3.1.2/ /opt/openmpi-3.1.2
%post
### Install prerequisites
I can get the mpi.sif successfully after the building.
But i ran mpicc in container, it is wrong:
Singularity> mpicc
mpicc: error while loading shared libraries: libnuma.so.1: cannot open shared object file: No
such file or directory
Singularity> echo $PATH
/opt/openmpi-3.1.2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Singularity> cd /opt/openmpi-3.1.2/bin/
Singularity> ls
aggregate_profile.pl mpiCC mpif77 mpirun ompi_info ompi-top orte-clean
orte-info orte-server oshcc oshfort profile2mat.pl shmemcc shmemfort
mpic++ mpicxx mpif90 ompi-clean ompi-ps opal_wrapper orted orte-ps
orte-top oshCC oshmem_info prun shmemCC shmemrun
mpicc mpiexec mpifort ompi-dvm ompi-server ortecc orte-dvm orterun
oshc++ oshcxx oshrun shmemc++ shmemcxx
In fact, i have mpi files in container, but it is wrong:
Singularity> ./mpicc
./mpicc: error while loading shared libraries: libnuma.so.1: cannot open shared object file:
No such file or directory
Singularity>ldd ./mpicc
linux-vdso.so.1 => (0x00007fff1d79f000)
libopen-pal.so.40 => /opt/openmpi-3.1.2/lib/libopen-pal.so.40 (0x00007f0a6cade000)
libm.so.6 => /lib64/libm.so.6 (0x00007f0a6c7dc000)
libnuma.so.1 => not found
librt.so.1 => /lib64/librt.so.1 (0x00007f0a6c5d4000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f0a6c3d1000)
libz.so.1 => /lib64/libz.so.1 (0x00007f0a6c1bb000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f0a6bfa5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0a6bd89000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0a6b9bb000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a6b7b7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0a6ce13000)
libnuma.so.1 => not found
libimf.so => not found
libsvml.so => not found
libirng.so => not found
libintlc.so.5 => not found
Who can give me a help?

Related

Why does the CMake Linux binary depend on libgtk3-noscd?

I'm using CMake 3.21.3 - from Kitware's download page (binary distribution). I've noticed that:
$ ldd `which cmake`
linux-vdso.so.1 (0x00007fff0ed12000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007fdc4a890000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdc4a88a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdc4a87f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdc4a85d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdc4a719000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdc4a554000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdc4a8d3000)
contains references to two unexpected libraries. One is librt, which is probably explained by its use within cmlibuv (which CMake in turn uses); but the other, which I can't explain, is libgtk3-nocsd. Why would the CMake binary (not cmake-gui mind you) use this library?
It's not linked against libgtk3-nocsd. Something in your environment has set LD_PRELOAD to add libgtk3-nocsd. Try running ldd again with LD_PRELOAD unset.
$ curl -s -L -O https://github.com/Kitware/CMake/releases/download/v3.21.3/cmake-3.21.3-linux-x86_64.tar.gz
$ shasum cmake-3.21.3-linux-x86_64.tar.gz
5461d4f066a728445e0b6be0e4d250b828323908 cmake-3.21.3-linux-x86_64.tar.gz
$ tar xf cmake-3.21.3-linux-x86_64.tar.gz
$ cd cmake-3.21.3-linux-x86_64/bin
$ shasum cmake
9c0032147cde3739e121c092013d13eb21c3ce34 cmake
$ unset LD_PRELOAD
$ ldd cmake
linux-vdso.so.1 (0x00007fffe0191000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f65af676000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f65af66b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f65af649000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f65af505000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f65af340000)
/lib64/ld-linux-x86-64.so.2 (0x00007f65af684000)

SVN / Apache Issue undefined symbol: apr_crypto_block_cleanup

I am using AlmaLinux 8 with svn/apache.
When trying to start my httpd service I am given the following status message:
Aug 12 17:54:06 domain.tld httpd[495168]: httpd: Syntax error on line 132 of /etc/httpd/conf/httpd2.conf: Syntax error on line 1 of /etc/httpd/conf/extra/httpd-svn.conf: Cannot load /usr/lib/apache/mod_dav_svn.so into server: /usr/lib64/libsvn_subr-1.so.0: undefined symbol: apr_crypto_block_cleanup
In the past, simply moving /usr/lib64/libsvn_subr-1.so.0 to /usr/lib64/libsvn_subr-1.so.0-old fixed the error but on this occasion (having updated dnf) this is not the case.
Struggling because I have limited debugging opportunities so if anything at all can be provided to help debug that would suffice as an answer. the only output I can find suitable for me is below.
linux-vdso.so.1 (0x00007ffd13835000)
libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0 (0x00007fb9de978000)
libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0 (0x00007fb9de76a000)
libsvn_fs_fs-1.so.0 => /usr/lib64/libsvn_fs_fs-1.so.0 (0x00007fb9de512000)
libsvn_fs_x-1.so.0 => /usr/lib64/libsvn_fs_x-1.so.0 (0x00007fb9de2ba000)
libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0 (0x00007fb9de09a000)
libsvn_fs_util-1.so.0 => /usr/lib64/libsvn_fs_util-1.so.0 (0x00007fb9dde96000)
libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0 (0x00007fb9ddc02000)
libaprutil-1.so.0 => /usr/lib/apache/libaprutil-1.so.0 (0x00007fb9dd9cd000)
libapr-1.so.0 => /usr/lib/apache/libapr-1.so.0 (0x00007fb9dd788000)
librt.so.1 => /usr/lib64/librt.so.1 (0x00007fb9dd580000)
libcrypt.so.1 => /usr/lib64/libcrypt.so.1 (0x00007fb9dd357000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fb9dd11c000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00007fb9dcf05000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007fb9dcd01000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007fb9dcae1000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb9dc71c000)
libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007fb9dc408000)
libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x00007fb9dc1e1000)
liblz4.so.1 => /usr/lib64/liblz4.so.1 (0x00007fb9dbfc4000)
libutf8proc.so.2 => /usr/lib64/libutf8proc.so.2 (0x00007fb9dbd7b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb9dedea000)
libm.so.6 => /usr/lib64/libm.so.6 (0x00007fb9db9f9000)
Currently svn is only served via svn hence I don't even have svn available at cli.
Please help!
Running the following fixed my problem:
tar xvf subversion-1.14.0.tar.gz
cd subversion-1.14.0
wget https://www.sqlite.org/2015/sqlite-amalgamation-3081101.zip -O sqlite-ation-3081101.zip
unzip sqlite-amalgamation-3081101.zip
mv sqlite-amalgamation-3081101 sqlite-amalgamation
./configure --prefix=/usr --with-apxs=/usr/sbin/apxs --with-apr=/usr/bin/apr-1-config --with-lz4=internal --with-utf8proc=internal
make -j4
mv subversion/mod_dav_svn/.libs/mod_dav_svn.so /usr/lib/apache/mod_dav_svn.so
Thanks anyway, hope this helps someone (most likely me) in the future.

CentOS 6 httpd killed by update

Panic Mode commences! I installed updates yesterday.
On restart, httpd yielded:
Starting httpd: /usr/sbin/httpd: symbol lookup error: `/usr/lib64/libaprutil-1.so.0: undefined symbol: apr_os_uuid_get
Running ldd -r generates the same message:
ldd -r /usr/sbin/httpd
linux-vdso.so.1 => (0x00007fffe82d9000)
libm.so.6 => /lib64/libm.so.6 (0x00007f121e5fd000)
libpcre.so.0 => /lib64/libpcre.so.0 (0x00007f121e3d1000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f121e1b1000)
libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007f121df8d000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f121dd56000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f121db2d000)
libdb-4.7.so => /lib64/libdb-4.7.so (0x00007f121d7b9000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007f121d587000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f121d369000)
libc.so.6 => /lib64/libc.so.6 (0x00007f121cfd5000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f121cdd1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f121eae5000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f121cbcc000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f121c953000)
librt.so.1 => /lib64/librt.so.1 (0x00007f121c74b000)
undefined symbol: apr_os_uuid_get (/usr/lib64/libaprutil-1.so.0)
Short of downloading apache source, what are the options.
I already did a yum clean all and made sure I'm using only the base repositories. No updates available, yadda.
I'm downloading the apache2 source code while I await the obvious quick-fix answer.
You have an extraneous 32bit version of libapr installed. Visible in the following line.
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007f121d587000)
You can find out what package owns that file by running rpm -qf /usr/lib/libapr-1.so.0.
That package might need upgrading (or removal if it is unused).

References to FFTW not resolved when linking with --as-needed

I have a linking problem which I cannot explain. The program contains references to FFTW functions in a file called fft.cpp. The linking command is as follows (I skipped the rest of object files):
/usr/bin/g++ common/CleanerND.cpp.2.o ... common/fft.cpp.2.o
-o cleaner3d -Wl,-Bstatic -Wl,-Bdynamic -lmkl_intel_lp64 -lmkl_sequential -lmkl_core
-lfftw3f -lgsl -lgslcblas -lm -lglib-2.0 -lz -lm -lpthread -fopenmp
The superfluous -Wl,-Bstatic -Wl,-Bdynamic options are generated by Waf, which I use as the build system. I use the default toolchain that comes with Ubuntu 12.04: GCC 4.6.3, binutils 2.22.
The problem is that the linker does not detect and resolve the references to the FFTW functions. When run, the program aborts with this message:
cleaner3d: symbol lookup error: cleaner3d: undefined symbol: fftwf_malloc
The output ofldd shows that FFTW is not being linked at all:
$ ldd cleaner3d
linux-vdso.so.1 => (0x00007fffa3193000)
libmkl_intel_lp64.so => /opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_intel_lp64.so (0x00007f6f16683000)
libmkl_sequential.so => /opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_sequential.so (0x00007f6f164d3000)
libmkl_core.so => /opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_core.so (0x00007f6f16300000)
libgsl.so.0 => /usr/lib/libgsl.so.0 (0x00007f6f15ec4000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f6f15bcf000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6f158d4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6f156b7000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6f153b7000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f6f151a8000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6f14f92000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6f14bd5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6f149d0000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f6f14793000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6f1458b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6f169b2000)
This is clearly the linker's fault, since the output of nm shows that it contains references to FFTW:
$ nm build/common/fft.cpp.2.o | grep fftw
U fftwf_destroy_plan
U fftwf_execute_dft
U fftwf_free
U fftwf_malloc
U fftwf_plan_dft_1d
U fftwf_plan_many_dft
I found out that this might be somehow related to the linker option --as-needed, which is passed by default since Ubuntu 12.04 - and indeed, when I add -Wl,--no-as-needed to the command line, the problem disappears. However, this workaround should not be necessary. I don't understand why the linker won't properly link FFTW with --as-needed enabled. Can anyone shine some light on this? Is this a linker bug? Why only the FFTW library is affected?

g++ linking problem

I'm having a weird linking problem and am only beginning programming with c++ so I'm not terribly sure what it means...
main.cpp
#include <iostream>
main(void)
{
return 0;
}
Compiling
esr#athena:~/programming/cpp$ g++ main.cpp
esr#athena:~/programming/cpp$ ./a.out
esr#athena:~/programming/cpp$ g++ main.cpp -L/home/esr/ogre/lib -lOgreMain
esr#athena:~/programming/cpp$ ./a.out
This executes just fine, however, when I link against another of the libraries in the same folder...
esr#athena:~/programming/cpp$ g++ main.cpp -L/home/esr/ogre/lib -lOgreMain -lOgreTerrain
esr#athena:~/programming/cpp$ ./a.out
./a.out: error while loading shared libraries: libOgreTerrain.so.1.7.1: cannot open shared object file: No such file or directory
So what's in that folder?
esr#athena:~/programming/cpp$ ls /home/esr/ogre/lib/
libOgreMain.so Sample_DynTex.so
libOgreMain.so.1.7.1 Sample_FacialAnimation.so
libOgrePaging.so Sample_Fresnel.so
libOgrePaging.so.1.7.1 Sample_Grass.so
libOgreRTShaderSystem.so Sample_Instancing.so
libOgreRTShaderSystem.so.1.7.1 Sample_Isosurf.so
libOgreTerrain.so Sample_Lighting.so
***libOgreTerrain.so.1.7.1*** Sample_Ocean.so
Edit: (the stars are for emphasis, not a file name)
It's right there! Any ideas on what I'm doing wrong?
Edit
Still having problems. Tried linking against all dependencies of libOgreTerrain and that doesn't seem to have satisfied the compiler.
ldd libOgreTerrain.so
linux-vdso.so.1 => (0x00007fff56bff000)
libOgreMain.so.1.7.1 => /home/esr/ogre/lib/libOgreMain.so.1.7.1 (0x00007fd3584c8000)
libOgrePaging.so.1.7.1 => /home/esr/ogre/lib/libOgrePaging.so.1.7.1 (0x00007fd35829b000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007fd357fee000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00007fd357de5000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00007fd357bca000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fd357893000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fd357681000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x00007fd35741c000)
libXaw.so.7 => /usr/lib/libXaw.so.7 (0x00007fd3571ac000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fd356f8f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fd356d8b000)
libfreeimage.so.3 => /usr/lib/libfreeimage.so.3 (0x00007fd3568bc000)
libzzip-0.so.13 => /usr/lib/libzzip-0.so.13 (0x00007fd3566b5000)
libz.so.1 => /lib/libz.so.1 (0x00007fd35649d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fd356196000)
libm.so.6 => /lib/libm.so.6 (0x00007fd355f13000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fd355cfd000)
libc.so.6 => /lib/libc.so.6 (0x00007fd355979000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007fd355774000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fd355556000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0x00007fd35533d000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x00007fd35512c000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fd354f28000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fd354d22000)
Changed compilation code to the following:
g++ main.cpp -L/home/esr/ogre/lib -lOgreMain -lOgreTerrain -L/lib -L/usr/lib -lfreetype -lSM -lICE -lX11 -lXext -lXt -lXaw -lpthread -lfreeimage -lxcb -lXmu -lXpm -lXau -lXdmcp -ldl -lzzip -lz -lstdc++ -lm -lgcc_s -lc
Which links against all dependencies as above afaik (uuid wouldn't link).
esr#athena:~/programming/cpp$ g++ main.cpp -L/home/esr/ogre/lib -lOgreMain -lOgreTerrain -L/lib -L/usr/lib -lfreetype -lSM -lICE -lX11 -lXext -lXt -lXaw -lpthread -lfreeimage -lxcb -lXmu -lXpm -lXau -lXdmcp -ldl -lzzip -lz -lstdc++ -lm -lgcc_s -lc
esr#athena:~/programming/cpp$ ./a.out
./a.out: error while loading shared libraries: libOgreTerrain.so.1.7.1: cannot open shared object file: No such file or directory
esr#athena:~/programming/cpp$ LD_LIBRARY_PATH=/home/esr/ogre/lib ./a.out
esr#athena:~/programming/cpp$
Edit 2
Linking of a.out
esr#athena:~/programming/cpp$ ldd a.out
linux-vdso.so.1 => (0x00007fff978a4000)
libOgreMain.so.1.7.1 => /usr/lib/libOgreMain.so.1.7.1 (0x00007f612d528000)
libOgreTerrain.so.1.7.1 => not found
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f612d2a0000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f612d097000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f612ce7c000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f612cb45000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f612c933000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x00007f612c6ce000)
libXaw.so.7 => /usr/lib/libXaw.so.7 (0x00007f612c45e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f612c241000)
libfreeimage.so.3 => /usr/lib/libfreeimage.so.3 (0x00007f612bd73000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f612bb55000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0x00007f612b93c000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x00007f612b72b000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f612b527000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f612b321000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f612b11d000)
libzzip-0.so.13 => /usr/lib/libzzip-0.so.13 (0x00007f612af15000)
libz.so.1 => /lib/libz.so.1 (0x00007f612acfd000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f612a9f7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f612a7e0000)
libm.so.6 => /lib/libm.so.6 (0x00007f612a55d000)
libc.so.6 => /lib/libc.so.6 (0x00007f612a1da000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007f6129fd4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f612dcfc000)
Resolution
Partially resolved thusly, I linked to the shared libraries in the /usr/lib folder, I'm not sure why g++ wouldn't look in there, but it just wouldn't.
Useful links here and here
It's rather simple.
The OS looks for libraries in the directories that exist in the ldconfig.
it seems that libOgreTerrain.so links against some other libraries that were not explicitly specified.
Try this first:
LD_LIBRARY_PATH=/home/esr/ogre/lib ./a.out
You can display dynamic linking paths like that:
ldd ./a.out