Is there a way to check the configuration of armadillo from a c++ program? I just want to make sure armadillo has been compiled with 'atlas' or 'openblas'
I found arma::arma_config cfg; but I have no idea what cfg contains. I've done some testing and found blas and atlas but openblas does not seem to be an option. Is there anywhere I can find a complete list of what cfg contains?
That is common misunderstanding. Armadillo uses the LAPACK/BLAS interface and you can switch the libraries out at will.
edd#rob:/tmp$ g++ -o armadillo_example armadillo_example.cpp -larmadillo
edd#rob:/tmp$ ./armadillo_example
A*trans(B) =
-0.3111 -0.3320 -0.8700 -0.8698
0.1312 -0.7760 -0.2394 -0.6150
-0.2320 -1.2993 -0.6748 -1.3584
-0.1677 -1.9175 0.6289 -0.5619
edd#rob:/tmp$ ldd armadillo_example
linux-vdso.so.1 (0x00007fff92b5b000)
libarmadillo.so.9 => /usr/lib/libarmadillo.so.9 (0x00007fe598ea5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe598cc4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe598b75000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe598b5a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe598970000)
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007fe598910000)
liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 (0x00007fe598271000)
libarpack.so.2 => /usr/lib/x86_64-linux-gnu/libarpack.so.2 (0x00007fe598229000)
libsuperlu.so.5 => /usr/lib/x86_64-linux-gnu/libsuperlu.so.5 (0x00007fe5981b9000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe598ef1000)
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007fe596025000)
libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007fe595d5d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe595d39000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fe595cef000)
edd#rob:/tmp$
The armadillo shared library has similar links:
edd#rob:/tmp$ ldd /usr/lib/libarmadillo.so.9
linux-vdso.so.1 (0x00007ffc98853000)
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f6043563000)
liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 (0x00007f6042ec6000)
libarpack.so.2 => /usr/lib/x86_64-linux-gnu/libarpack.so.2 (0x00007f6042e7e000)
libsuperlu.so.5 => /usr/lib/x86_64-linux-gnu/libsuperlu.so.5 (0x00007f6042e0e000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6042c2d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6042ade000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6042ac1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f60428d7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f60435ff000)
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007f6040743000)
libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007f604047b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6040459000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f604040d000)
edd#rob:/tmp$
On my Ubuntu system /usr/lib/x86_64-linux-gnu/libblas.so.3 is a softlink that gets updated when another BLAS/LAPACK package is installed allowing you to easil switch (which I use e.g. in this GitHub repo to show how to easily install MKL.
The structure of arma_config can be found in /usr/include/armadillo_bits/arma_config.hpp or wherever locate arma_config finds the file.
Related
I've already read this, this and this.
I've installed OpenCV in a costum path /home/luca/ParallelOpenCV/install_icpc/lib, where there is libopencv_core.so:
luca#jarvis:~$ ldd /home/luca/ParallelOpenCV/install_icpc/lib/libopencv_core.so
linux-vdso.so.1 => (0x00007ffccb389000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f46af719000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f46af410000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f46af1f2000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f46aefea000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f46aedd0000)
libimf.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libimf.so (0x00007f46ae8e3000)
libsvml.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libsvml.so (0x00007f46ad9d8000)
libirng.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libirng.so (0x00007f46ad663000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f46ad2e0000)
libiomp5.so => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libiomp5.so (0x00007f46acf3d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f46acd27000)
libintlc.so.5 => /opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64/libintlc.so.5 (0x00007f46acabc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f46ac6f3000)
/lib64/ld-linux-x86-64.so.2 (0x000055f67574e000)
I added the path to LD_LIBRARY_PATH and I executed ldconfig, but:
luca#jarvis:~$ ldd libopencv_core.so
ldd: ./libopencv_core.so: No such file or directory
What am I missing?
From man ldd:-
NAME
ldd - print shared object dependencies
SYNOPSIS top
ldd [option]... file...
DESCRIPTION
ldd prints the shared objects (shared libraries) required by each
program or shared object specified on the command line. An example
of its use and output is the following:
$ ldd /bin/ls
linux-vdso.so.1 (0x00007ffcc3563000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f87e5459000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f87e5254000)
libc.so.6 => /lib64/libc.so.6 (0x00007f87e4e92000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f87e4c22000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f87e4a1e000)
/lib64/ld-linux-x86-64.so.2 (0x00005574bf12e000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f87e4817000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f87e45fa000)
The output of your command:
luca#jarvis:~$ ldd libopencv_core.so
ldd: ./libopencv_core.so: No such file or directory
says that the program or shared object supposedly specified on the
commandline does not exist in the implied directory = ./ = /home/luca.
We know it exists in /home/luca/ParallelOpenCV/install_icpc/lib.
If you run ldd file, where file, after shell expansion, is the pathname
of an existing file, then ldd will display the dynamic dependencies
of that file, as discovered by the dynamic linker with its usual reliance upon
the current ldconfig configuration and its usual regard to the operative
LD_LIBRARY_PATH environment setting. It will not search your system
for files that might be alternate candidates for a file that does not exist
and display the dynamic dependencies of those candidates.
I write a simple llvm plugin pass that requires opt to load xxx.so file and run a ModulePass. The strange thing is that when I use deb package opt (e.g., from apt-get, let's call it opt-3.7), the plugin works fine (the drawback is that it is a Release build); however when I use the opt I build myself (simplify call it opt), it frequently complains:
Error opening 'xxx.so': xxx.so: undefined symbol: _ZNK4llvm12FunctionPass17createPrinterPassERNS_11raw_ostreamERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
using c++filt I know that opt cannot find llvm::FunctionPass::createPrinterPass(llvm::raw_ostream&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const.
It's a big strange since I didn't use any FunctionPass in the pass; but let's ignore this and continue.
I then checked the result of ldd opt
linux-vdso.so.1 => (0x00007ffd5c1ce000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f16a90d3000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f16a8ea9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f16a8c8c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f16a8a72000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f16a86ef000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f16a83e6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f16a81d0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f16a7e06000)
/lib64/ld-linux-x86-64.so.2 (0x00005645f6210000)
and ldd opt-3.7
linux-vdso.so.1 => (0x00007ffc51bc0000)
libLLVM-3.7.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-3.7.so.1 (0x00007fec3f725000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fec3f3a2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec3efb1000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fec3ed97000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec3eb79000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fec3e971000)
libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007fec3e739000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fec3e50f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fec3e30b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec3e002000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fec3ddeb000)
/lib64/ld-linux-x86-64.so.2 (0x000055bad2080000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fec3dbd6000)
The difference, I guess, is the so file libLLVM-3.7.so.1.
So where didn't I get wrong?
BTW, my llvm was built w/o and w/ -DLLVM_BUILD_LLVM_DYLIB=1, both has the undefined symbol issue.
We had exactly the same error when using LLVM plugin with CLANG 3.9. We then found the solution here: https://github.com/klee/klee/issues/336
The explanation is that ABI for libstdc++ used for LLVM and your plugin is different. To solve this problem you need to recompile your plugin with the following flag "-D_GLIBCXX_USE_CXX11_ABI=0".
Check this Makefile for LLVM plugin as example: https://github.com/SamAinsworth/reproduce-cgo2017-paper/blob/master/package/plugin-llvm-sw-prefetch-pass/Makefile
I'm having issues linking my application to a shared object. I've cleanly built buildroot including packages host-thrift and host-openssl.
ldd --verbose libthrift.so yields the following:
./libthrift.so: /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libcrypto.so.1.0.0: no version information available (required by ./libthrift.so)
./libthrift.so: /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libssl.so.1.0.0: no version information available (required by ./libthrift.so)
./libthrift.so: /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libssl.so.1.0.0: no version information available (required by ./libthrift.so)
linux-vdso.so.1 => (0x00007ffda06bc000)
libssl.so.1.0.0 => /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libssl.so.1.0.0 (0x00007f0c37c10000)
libcrypto.so.1.0.0 => /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libcrypto.so.1.0.0 (0x00007f0c377d9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0c375bb000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0c3723f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0c36f39000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0c36b74000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0c3695d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0c36759000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0c38129000)
Version information:
./libthrift.so:
libgcc_s.so.1 (GCC_3.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
libstdc++.so.6 (CXXABI_1.3.1) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.9) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libstdc++.so.6 (CXXABI_1.3) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so.0 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libpthread.so.0
libcrypto.so.1.0.0 (OPENSSL_1.0.0) => not found
libssl.so.1.0.0 (OPENSSL_1.0.1) => not found
libssl.so.1.0.0 (OPENSSL_1.0.0) => not found
/home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libssl.so.1.0.0:
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libcrypto.so.1.0.0:
libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libpthread.so.0:
ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/usr/lib/x86_64-linux-gnu/libstdc++.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 (GCC_4.2.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.3) => /lib/x86_64-linux-gnu/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.18) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libm.so.6:
libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
/lib/x86_64-linux-gnu/libgcc_s.so.1:
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libdl.so.2:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
Which indicates that there's something fishy:
./libthrift.so: /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libcrypto.so.1.0.0: no version information available (required by ./libthrift.so)
./libthrift.so: /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libssl.so.1.0.0: no version information available (required by ./libthrift.so)
./libthrift.so: /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/libssl.so.1.0.0: no version information available (required by ./libthrift.so)
As far as I've been able to google, this can happen when you build against a newer version of a library than the one you're trying to run with. But this is not the case here (unless my host's libraries are playing me a trick I can't see).
Also:
libcrypto.so.1.0.0 (OPENSSL_1.0.0) => not found
libssl.so.1.0.0 (OPENSSL_1.0.1) => not found
libssl.so.1.0.0 (OPENSSL_1.0.0) => not found
Yet these files are there in the same folder built at the same time.
What I've tried:
1.
Playing with LD_LIBRARY_PATH and LIBRARY_PATH does not affect the issue since libthrift.so is built with rpath:
readelf -a libthrift.so | grep PATH
0x000000000000000f (RPATH) Library rpath: [/home/ano/workspace/source/open-source/buildroot/output/host/usr/lib]
2.
Checking file types:
> file libthrift.so
libthrift.so: symbolic link to `libthrift-0.9.2.so'
> file libthrift-0.9.2.so
libthrift-0.9.2.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2dd133dea99a83cd5a8a9873e91503df3b7d7359, not stripped
> file libssl.so.1.0.0
libssl.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=52c9028d053f16d05b6e1ff35605019182c8b28d, not stripped
3. (new info)
Copied my local /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 and /lib/x86_64-linux-gnu/libssl.so.1.0.0 into /home/ano/workspace/source/open-source/buildroot/output/host/usr/lib/.
This did infact fix the problem, so now, if I understand it correctly, it seems like when libthrift.so was built in buildroot, it used my local /lib libraries instead of the ones that was built by buildroot itself.
It turned out to be a bug in the host-thrift package in buildroot. host-thrift declared a dependency to host-boost but did not specify --with-boost and --with-boost-libdir config options for host build.
I set HOST_THRIFT_CONF_OPTS to:
HOST_THRIFT_CONF_OPTS = --with-sysroot=$(HOST_DIR) \
--with-boost \
--with-boost-libdir=$(HOST_DIR)/usr/lib \
--disable-tests \
--disable-tutorial
and that fixed the problem.
I know there is a lot about this on the internet and I have tried most of it without luck. Most solutions says that en environment variable is missing aka (LD_LIBRARY_PATH) which i pointed it to the file in user and root but it still does not pick it up. I am not sure what exactly is looking for the library or how to fix this??
Any ideas?
EDIT
ldd output:
linux-vdso.so.1 => (0x00007fffb97ff000)
libmysqlcppconn.so.7 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f002fdb3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f002fb9c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f002f7dd000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f002f5c0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f002f2c3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f00300c7000)
Here's how you correctly set the library path...
If your library is at /usr/local/lib/libmylib.so.4 and your program is ./myprog:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib ./myprog
I'm trying to Hoard allocator to work, but it seems it doesn't. I have a benchmark application that does a lot of dynamic memory management. The execution time for Hoard and glibc memory manager is the same. It makes me wonder if I'm doing the right thing.
What I do is...
export LD_PRELOAD="/path/libhoard.so"
g++ main.cpp -O3 -o bm -lpthread -lrt
Shouldn't I have to link to Hoard allocator? Does it matter what path (in LD_PRELOAD) is, or can I have whatever path?
I'm running Ubuntu 8.04, and g++ 4.2.4
Cheers
No one knows any Linux command (such as grep) to find out if Hoard is loaded properly, and is the actual allocator used?
Author of Hoard here.
(a) Any path for LD_PRELOAD is fine (as long as it is correct).
(b) To see whether your code is using Hoard or not, use the ldd command. If everything went according to plan, then you will see the Hoard library (notice the second line after the second invocation of ldd).
Best,
-- Emery Berger
bash-3.2$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fffe6dfd000)
librt.so.1 => /lib64/librt.so.1 (0x0000003159600000)
libacl.so.1 => /lib64/libacl.so.1 (0x000000315e200000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x000000315d200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003154e00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003155a00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003154a00000)
libattr.so.1 => /lib64/libattr.so.1 (0x0000003162000000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003155600000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x000000315ce00000)
bash-3.2$ export LD_PRELOAD=$PWD/libhoard.so
bash-3.2$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff24bfd000)
/nfs/cm/users1/emery/scratch/projects/hoard/trunk/src/libhoard.so (0x00002b4885f42000)
librt.so.1 => /lib64/librt.so.1 (0x0000003159600000)
libacl.so.1 => /lib64/libacl.so.1 (0x000000315e200000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x000000315d200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003154e00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003155600000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003155a00000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000315b200000)
libm.so.6 => /lib64/libm.so.6 (0x0000003155200000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000315aa00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003154a00000)
libattr.so.1 => /lib64/libattr.so.1 (0x0000003162000000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x000000315ce00000)
bash-3.2$