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.
Related
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)
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?
I just tried to install apache 2.4.25 with these configure parameters
./configure --prefix=/opt/apache2/ --with-apr=/opt/apr --with-apr-util=/opt/apr-util --with-pcre=/opt/pcre --enable-ssl --with-ssl=/usr/local/ssl
and seems no problem. But when I tried to make, it halted and says
/usr/bin/ld: cannot find -lcrypt
Then I tried to find out whether libcrypt* library is loaded, and yes is there
[root#localhost httpd-2.4.25]# ldconfig -p | grep libcrypt
libcryptui.so.0 (libc6,x86-64) => /usr/lib64/libcryptui.so.0
libcryptsetup.so.1 (libc6,x86-64) => /lib64/libcryptsetup.so.1
libcrypto.so.10 (libc6,x86-64) => /usr/lib64/libcrypto.so.10
libcrypto.so.1.1 (libc6,x86-64) => /usr/lib64/libcrypto.so.1.1
libcrypto.so (libc6,x86-64) => /usr/lib64/libcrypto.so
libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.18) => /lib64/libcrypt.so.1
libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.18) => /usr/lib64/libcrypt.so.1
Any clue about this?
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).
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?