Which openSUSE rpm contains dmalloc? No repository have it. Tried to build it from src.rpm found for SLE 12. However it does not contain libdmalloc* libraries. How to do LD_PRELOAD="libdmalloc.so" ./my_program? Or it is not necessary?
Works without LD_PRELOAD, seems not necessary any more, just simple:
1) eval `dmalloc -d 0 -l leak.log -p log-non-free`
2) ./my_program
However program should be built and linked with dmalloc:
#include <dmalloc.h>
Link:
$ g++ -L/usr/lib64 -ldmalloc ...
Related
I downloaded and built gcc 4.8.1 on my desktop, running 64-bit Ubuntu 12.04. I built it out of source, like the docs recommend, and with the commands
../../gcc-4.8.1/configure --prefix=$HOME --program-suffix=-4.8
make
make -k check
make install
It seemed to pass all the tests, and I installed everything into my home directory w/ the suffix -4.8 to distinguish from the system gcc, which is version 4.6.3.
Unfortunately when I compile c++ programs using g++-4.8 it links to the system libc and libstdc++ rather than the newer ones compiled from gcc-4.8.1. I downloaded and built gcc 4.8 because I wanted to play around with the new C++11 features in the standard library, so this behaviour is definitely not what I wanted. What can I do to get gcc-4.8 to automatically link to the standard libraries that came with it rather than the system standard libraries?
When you link with your own gcc you need to add an extra run-time linker search path(s) with -Wl,-rpath,$(PREFIX)/lib64 so that at run-time it finds the shared libraries corresponding to your gcc.
I normally create a wrapper named gcc and g++ in the same directory as gcc-4.8 and g++-4.8 which I invoke instead of gcc-4.8 and g++-4.8, as prescribed in Dynamic linker is unable to find GCC libraries:
#!/bin/bash
exec ${0}SUFFIX -Wl,-rpath,PREFIX/lib64 "$#"
When installing SUFFIX and PREFIX should be replaced with what was passed to configure:
cd ${PREFIX}/bin && rm -f gcc g++ c++ gfortran
sed -e 's#PREFIX#${PREFIX}#g' -e 's#SUFFIX#${SUFFIX}#g' gcc-wrapper.sh > ${PREFIX}/bin/gcc
chmod +x ${PREFIX}/bin/gcc
cd ${PREFIX}/bin && ln gcc g++ && ln gcc c++ && ln gcc gfortran
(gcc-wrapper.sh is that bash snippet).
The above solution does not work with some versions of libtool because g++ -Wl,... -v assumes linking mode and fails with an error.
A better solution is to use specs file. Once gcc/g++ is built, invoke the following command to make gcc/g++ add -rpath to the linker command line (replace ${PREFIX}/lib64 as necessary):
g++ -dumpspecs | awk '/^\*link:/ { print; getline; print "-rpath=${PREFIX}/lib64", $0; next } { print }' > $(dirname $(g++ -print-libgcc-file-name))/specs
I just had the same problem when building gcc-4.8.2. I don't have root access on that machine and therefore need to install to my home directory. It took several attempts before I figured out the magic required to get this to work so I will reproduce it here so other people will have an easier time. These are the commands that I used to configure gcc:
prefix=/user/grc/packages
export LDFLAGS=-Wl,-rpath,$prefix/lib
export LD_RUN_PATH=$prefix/lib
export LD_LIBRARY_PATH=$prefix/lib
../../src/gmp-4.3.2/configure --prefix=$prefix
../../src/mpfr-2.4.2/configure --prefix=$prefix
../../src/mpc-0.8.1/configure --prefix=$prefix --with-mpfr=$prefix --with-gmp=$prefix
../../src/gcc-4.8.2/configure --prefix=$prefix --with-mpfr=$prefix --with-gmp=$prefix --with-mpc=$prefix --enable-languages=c,c++
That got me a working binary but any program I built with that version of g++ wouldn't run correctly unless I built it with the -Wl,-rpath,$prefix/lib64 option. It is possible to get g++ to automatically add that option by providing a specs file. If you run
strace g++ 2>&1 | grep specs
you can see which directories it checks for a specs file. In my case it was $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/specs so I ran g++ -dumpspecs to create a new specs file:
cd $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
$prefix/bin/g++ -dumpspecs > xx
mv xx specs
and then edited that file to provide the -rpath option. Search for the lines like this:
*link_libgcc:
%D
and edit to add the rpath option:
*link_libgcc:
%D -rpath /user/grc/packages/lib/%M
The %M expands to either ../lib or ../lib64 depending on whether you are building a 32-bit or a 64-bit executable.
Note that when I tried this same trick on an older gcc-4.7 build it didn't work because it didn't expand the %M. For older versions you can remove the %M and just hardcode lib or lib64 but that is only a viable solution if you only ever build 32-bit executables (with lib) or only ever build 64-bit executables (with lib64).
gcc -print-search-dirs will tell you where your compiler is looking for runtime libraries, etc. You can override this with the -B<prefix> option.
After installing boost from EPEL 5 on 64-bit CentOS 5.8 I run insto strange problem. I cannot link in other way then providing full path. I.e this works:
g++ ... /usr/lib64/libboost_python.so.5
But this cannot find -lboost_python
g++ ... -L/usr/lib64/ -lboost_python
What could be wrong?
PS. LD_LIBRARY_PATH does not help. It do finds some libraries but even symlinking into /usr/lib does not help. I am building 64-version of program (checked by file *.o).
Try to add a symlink : ln -s /usr/lib64/liboost_python.so /usr/lib64/libboost_python.so.5, then try again.
I'm trying to call R from c++ on linux via RInside, I compiled R-2.15.1 from source with gcc version 4.5.3 (Debian 4.5.3-1) , I don't have sudo rights to use apt-get install. I'm using OpenBlas and a system optimized lapack. The blas and lapack libraries work fine for many scalapack applications
I installed R with
./configure --with-blas="-I/lib/OpenBLAS-v0.2.3-0/xianyi-OpenBLAS-48f075c/install/include -L/lib/OpenBLAS-v0.2.3-0/xianyi-OpenBLAS-48f075c/install/lib -lopenblas -lgfortran" --with-lapack="/usr/lib/liblapack.so -lgfortran" --enable-BLAS-shlib=yes --enable-R-shlib --enable-R-static-lib --prefix= .
which installed and runs fine,I ran make check with no errors, also all the packages (Rcpp and RInside) installed fine..
however when i use the given RInside makefile , the basic hello world example from /standard/rinside_sample0.cpp compiles! but it does not run and i get the following error
./rinside_sample0: error while loading shared libraries: libRblas.so: cannot open shared object file: No such file or directory
the file libRblas.so exists and is in the R/lib folder,
when i try to link it manually with the g++ command the make file creates or linking as follows i get a segmentation fault
/R/lib/libRblas.so ./hello_world
Segmentation fault
EDIT: heres how the example make file tries to compile an example, (which compiles fine) but won't run with the above missing libRblas.so error
g++ -I/nfs/user03/jimmie21/libs/lib64/R/include -I/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/include -I/nfs/user03/jimmie21/libs/lib64/R/library/RInside/include -g -O2 -Wall -I/usr/local/include hello_world.cpp -L/nfs/user03/jimmie21/libs/lib64/R/lib -lR -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRblas -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRlapack -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRblas -L/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/lib -lRcpp -Wl,-rpath,/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/lib -L/nfs/user03/jimmie21/libs/lib64/R/library/RInside/lib -lRInside -Wl,-rpath,/nfs/user03/jimmie21/libs/lib64/R/library/RInside/lib -o hello_world
Couple of things:
Reproducible examples, please
You have a non-standard setup
With the script from 1), try it on a standard setting as that is how Rcpp / RInside get developed and tested (on Ubuntu / Debian)
The Rcpp test suite now contains almost 800 unit tests from around 350 unit test functions. These do not seg.fault, so the issue is at your end. Similarly, RInside has dozens of examples in the four examples/ subdirectories. This also works.
It may be as easy as tweaking the Makefile / Makevars files to make sure you get your libraries in all cases. But we can't tell as there is nothing reproducible here.
Edit If you want to link with libRblas.so then you have a completely non-standard setup as the R packages for Debian / Ubuntu as use the external BLAS. Again, not an RInside issue.
I fixed the problem by adding the R install path lib ../R/lib: to the beginning of LD_LIBRARY_PATH after that all the examples compiled and run fine
I'm trying to build a 32-bit application on Ubuntu 11.04 x64. I'm having some issues with the build because of linker errors with libboost. The build statement has -lboost_system in it, but when I try to build I get a bunch of these:
CommunicationModule.cpp:(.text+0x68c1): undefined reference to boost::system::generic_category()
CommunicationModule.cpp:(.text+0x68d7): undefined reference to boost::system::system_category()
Everything I've found on google says I need to link to the boost_system library. One place I found says to try linking to it directly, but when i do locate boost_system the result is empty. When I try doing a sudo apt-get install libboost-system-dev it tells me that it's already installed. I'm kind of at a loss here. The library is installed, but it's not being found by locate?
Can anyone tell me what I need to do to properly link to boost::system? I'm fairly new to linux and the complexities of compilers so any help here would be appreciated.
Update:
Here is the output of dpkg -L libboost-system1.42-dev:
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libboost-system1.42-dev
/usr/share/doc/libboost-system1.42-dev/copyright
/usr/share/doc/libboost-system1.42-dev/NEWS.Debian.gz
/usr/share/doc/libboost-system1.42-dev/README.Debian.gz
/usr/lib
/usr/lib/libboost_system.a
/usr/lib/libboost_system-mt.so
/usr/lib/libboost_system-mt.a
/usr/lib/libboost_system.so
Is there a flag I can use to link to one of these directly? I tried using -L /usr/lib/libboost_system.so and -L /usr/lib/libboost_system-mt.so and neither of those fixed the issue. Same with just adding /usr/lib/libboost_system.a and /usr/lib/libboost_system-mt.a to the build statement.
Here is the compilation line:
g++ -m32 -Wl,-O1 -o UTNaoTool [.o files] -L/usr/lib32 -lqglviewer-qt4 -lqwt-qt4 -lboost_system -lboost_thread -lQtXml -lQtOpenGL -lQtGui -lQtNetwork -lQtCore -lGLU -lpthread
Update 2:
I downloaded boost 1.49 and built everything for 32-bit and that seemed to help. A lot of the errors went away, but now I still have these:
CommunicationModule.cpp:(.text+0x68c1): undefined reference to
boost::system::get_generic_category()
Note that the function is different. So all of my errors are regarding undefined references to get_system_category() and get_generic_category() now. I tried adding a -lboost_filesystem to the build command but that didn't fix this, and I made sure it was referencing the 32-bit library that I built when I built libboost_system.
Looking at my own installation, it seems libboost-system-dev does not install the libraries. Using dpkg to tell me what was installed bz libboost-system-dev I get:
$ dpkg -L libboost-system-dev
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libboost-system-dev
/usr/share/doc/libboost-system-dev/copyright
/usr/share/doc/libboost-system-dev/changelog.gz
Poking around, I think you need to install libboost-system1.48.1 (or some other version).
sudo apt-get install libboost-system1.XX.Y
You can also search fo rthe libraries using the find command, for example, search under /usr for all files starting with libboost_system:
find /usr -name "libboost_system*"
Edit: Since you are cross-compiling from a 64 bit OS to a 32 bit one, you need 32 bit versions of the boost libraries. I would be tempted to set up a small 32 bit virtual machine to do this, rather than cross-compiling all the dependencies.
I had the same problem with boost_serialization here is what i found out after couple of googling..
first this library need to be compiled separately :
so after downloading the boost library ,extract it and execute sudo ./bootstrap.sh' then
sudo ./b2 --with-system
after this step you should be find a result when executing locate boost_system
then to link it manually I did:
both should work
g++ boostexample.cpp -o run /PATH/libboost_serialization.a
g++ boostexample.cpp -o run -L/PATH/ -lboost_serialization
well this is a little work around and I'm still looking for how to link the library properly
I hope this helped :)
Here's the current situation I'm in:
I want to distribute a binary app on Linux that would run on several distros (not all of them, just the main ones matter at the moment, let's focus on Ubuntu and Fedora for the sake of this discussion). The app in question links to libbz2 for some of its work. A simple "Hello World" will illustrate the situation :
/* main.cpp */
#include <iostream>
int main(int argc, char* argv[])
{
std::cout << "Hello World!\n";
return 0;
}
The app is built as such :
g++ -lbz2 -o test.bin main.cpp
My build system is on Ubuntu. When I perform a check with ldd on the resulting binary, it lists libbz2.so.1.0 as a runtime dependency. When I take this app to a Fedora machine, the app doesn't run and ldd reveals that it can't find libbz2.so.1.0. Fedora only has libbz2.so.1 and libbz2.so.1.0.4, but not libbz2.so.1.0.
Red Hat's Bugzilla database reveals that this behavior is not a bug, but a feature. I don't really need libbz2.so.1.0, and I would be satisfied with simply linking to libbz2.so.1, but I have yet to figure out how.
I have seen a similar question asked here previously, but the accepted answer (You can pass the actual .so file instead of -l on the linker command line) doesn't seem to work. I tried building with the following command :
g++ /lib/libbz2.so.1 -o test.bin main.cpp
However, ldd still mentions that the app depends on libbz2.so.1.0, even though I passed the full name to g++.
Now, the question is, is there a way on Ubuntu to build the app to have it depend only on libbz2.so.1 rather than on libbz2.so.1.0?
Thanks.
Here's a bit of background to explain what got linked. On ELF platforms the -L and -l flags you pass only locate the binary at link time. If the linker linker determines that a library is required it generates a reference to the SONAME in that binary, regardless of what it was called. For example:
$ objdump -p /lib64/libbz2.so.1 | grep SONAME
SONAME libbz2.so.1
So regardless of what libbz2 is named, that is what will show up as a dependency. Again by example, doing something totally whacked:
$ ln -s /lib64/libbz2.so.1 libblah.so
$ g++ t.C -L. -l blah
You have the apparency of having linked to libblah but because its the SONAME in that binary that matters, your dependency is still this libbz2.so.1
$ ldd a.out | grep bz2
libbz2.so.1 => /lib64/libbz2.so.1 (0x00002b3d1a000000)
Other than the -static trickery (which can break things in interesting ways), there is not easy way out of the mess (ideally the library would do nice symbol versioning like glibc and never or rarely change its SONAME).
Why don't you just link statically instead?
I have done that in the past for builds on Ubuntu and deployment on RHEL which works just fine using static builds.