g++ linking problem - g++

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

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)

Why the command in singularity container can not be run?

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?

CMake link shared library to system version instead own

I have my own libusb version inside the project's source directory, that I find with:
find_path(LibUsb_INCLUDE_DIR NAMES libusb.h PATHS ${CMAKE_CURRENT_SOURCE_DIR}/LibUsb/Include)
if(NOT LibUsb_INCLUDE_DIR)
message(FATAL_ERROR "LibUsb: include directory not found")
endif()
find_library(LibUsb_LIBRARY NAMES usb-1.0 libusb-1.0 PATHS ${OUTPUT_BIN_DIR})
if(NOT LibUsb_LIBRARY)
message(FATAL_ERROR "LibUsb: library not found")
endif()
add_library(LibUsb SHARED IMPORTED GLOBAL)
set_target_properties(LibUsb PROPERTIES IMPORTED_LOCATION ${LibUsb_LIBRARY})
set_target_properties(LibUsb PROPERTIES IMPORTED_IMPLIB ${LibUsb_LIBRARY})
set_target_properties(LibUsb PROPERTIES IMPORTED_NO_SONAME ON)
set_target_properties(LibUsb PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${LibUsb_INCLUDE_DIR})
message(STATUS "LibUsb: found at ${LibUsb_LIBRARY}")
This run successfully where I get
-- LibUsb: found at /mnt/c/x/Build/Linux-Debug/Output/Bin/libusb-1.0.so
Then I link it with
target_link_libraries(${TARGET_NAME} ... LibUsb)
Where I inspected link.txt that CMake produces for that target:
/usr/bin/g++-4.8 -Wall -Werror -Wextra -Wno-missing-field-initializers -g ... -lusb-1.0
But when inspecting my binary I get
gal#GalA-T480:/mnt/c/x$ readelf -d Build/Linux-Debug/Output/Bin/myexe | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libusb-1.0.so.0]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
gal#GalA-T480:/mnt/c/x$ ldd Build/Linux-Debug/Output/Bin/myexe
linux-vdso.so.1 (0x00007fffcd197000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f1a49930000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1a495a0000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1a49380000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1a49160000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1a48d60000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f1a48b40000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1a48790000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1a49c00000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1a48580000)
gal#GalA-T480:/mnt/c/x$
I don't get why the executable searches for libusb-1.0.so.0 and not libusb-1.0.so. I also don't get why it finds it at system directories and not my own.
Can I utilize RPATH somehow to work it out? Preferably using CMake?

/usr/bin/ld: cannot find -lcrypt

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?

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?