I am on ubuntu 16.04.
Here what I did:
installed gperftools :
sudo apt-get install google-perftools libgoogle-perftools-dev
downloaded FindGperftools.cmake from: https://github.com/vast-io/vast/blob/master/cmake/FindGperftools.cmake
renamed FindGperftools.cmake to GperftoolsConfig.cmake and placed it in a cmake folder in my package
added to CMakelists.txt:
set (Gperftools_DIR "${CMAKE_CURRENT_LIST_DIR}/cmake/")
find_package(Gperftools REQUIRED)
in same CMakelists.txt, link my executable:
target_link_libraries(my_executable ${GPERFTOOLS_PROFILER})
in a terminal, export the CPUPROFILE environment variable:
export CPUPROFILE=/my_path/prof.out
in the same terminal, run the executable:
./my_executable
There is no error message, but the log file /my_path/prof.out is not created.
If I run "ldd" on "my_executable", it does not show any linkage against profiler (ldd ./my_executable | grep profil does not result in anything).
Yet, when looking at files in the build folder, the compiler seems to do the linkage (-lprofile is there).
Anything I may have forgotten?
Note: not sure it is relevant, but I use catkin.
This looks like ubuntu's (and non-standard) linker feature to not link libraries which symbols are directly not used. Try adding -Wl,-no-as-needed to your LDFLAGS (and make sure it is passed before -lprofiler).
Related
I have this problem, I am trying to build caffe on debian machine, I will build everything but at the end at linking I get multiple undefined references to google::protobuf::...
I am attaching file with build log, containing error messages (build_caffe.txt).
Both libprotobuf-dev and protoc are installled. (output of dpkg -s is in proto.txt)
Here is how I build caffe.
export CXX=g++-4.9
export CC=gcc-4.9
cmake -D CUDA_HOST_COMPILER=/usr/bin/x86_64-linux-gnu-gcc-4.9 -D CUDA_USE_STATIC_CUDA_RUNTIME=OFF ..
make all
Does anyone know a solution for this problem please?
proto.txt
build_caffe.txt
Looks like your protobuf was compiled using a different version of gcc. Try to remove protobuf from your system and install it from sources, using the same gcc version you would like to use fro Caffe. (/usr/bin/x86_64-linux-gnu-gcc-4.9 according to your command).
EDIT:
If you can't install the updated protobuf, edit $CAFFE_ROOT/cmake/ProtoBuf.cmake and make the following changes:
#find_package( Protobuf REQUIRED ) # 1. Comment out this line
# 2. explicitly define protobuf's directories
set(PROTOBUF_INCLUDE_DIR path_to_protobuf/src/google/protobuf)
set(PROTOBUF_LIBRARIES path_to_where_protobuf_libs_are_built_to)
# 3. Explicitly set the full path to protoc executable
set(PROTOBUF_PROTOC_EXECUTABLE path_to_where_the_new_protoc_executable_is_build_to)
# ... Continue as usual
list(APPEND Caffe_INCLUDE_DIRS PUBLIC ${PROTOBUF_INCLUDE_DIR})
list(APPEND Caffe_LINKER_LIBS PUBLIC ${PROTOBUF_LIBRARIES})
#...
I have to compile a software that depends on METIS library, but whose CMake thing was written by disabling all the places where METIS was needed. Now, I have to re-enable that code again and thus the code depends now on METIS.
I installed metis-5.1.0 from source, and I wrote a CMake module to find it (actually I used this one). I modify the CMakeLists.txt accordingly, basically adding the following lines
find_package(METIS REQUIRED)
if (METIS_FOUND)
include_directories(SYSTEM ${METIS_INCLUDE_PATH})
else (METIS_FOUND)
message (SEND_ERROR "This application cannot compile without METIS")
endif (METIS_FOUND)
and, at the end,
target_link_libraries(<my_executable> ${METIS_LIBRARIES})
After cmake, it seems everything is fine, because cmake prints:
-- Found METIS: /usr/local/include
-- METIS libraries /usr/local/lib/libmetis.a
...
-- Configuring done
-- Generating done
-- Build files have been written to: <mylocation>
However, after I run make, I get
undefined reference to `METIS_WPartGraphKway'
undefined reference to `METIS_WPartGraphRecursive'
How can I solve?
EDIT:
As an additional information, when I compile with make VERBOSE=1, the linker seems to look for the right library, as it includes /usr/local/lib/libmetis.a, which corresponds to the location that cmake was specifying and which also exists. Moreover, when I look into the library with nm /usr/local/lib/libmetis.a, I see:
00000000000001c0 T METIS_WPartGraphKway
00000000000009c0 T METIS_WPartGraphRecursive
P.S.: In Ubuntu 17.04, I have tried with metis-5.1.0, metis-4.0.3 and also installing with sudo apt-get install libmetis-dev. In the latter case I find libmetis.so instead of libmetis.a, but, also in this case, this is correctly recognized by cmake, correctly looked for by the linker, but at the end I get the same error.
I also tried sudo apt-get install libmetis-dev, installing from source metis-5.1.0 and metis-3.0.6 on Ubuntu 14.04 and I had the same problem.
This seems a hard-to-solve error, as many people ask the same question in this page of the METIS formum.
I have also tried to add -lmetis at the end of the compilation command, as suggested here
As an additional information, I did a grep WPartGraphKway in the METIS source folder. In version 5.1.0 there is no such string. In version 4.0.3 there is.
I solved doing this:
I install metis-3.0
I run cmake for my software
I run make VERBOSE=1
I copy the last gcc command being printed
I paste it, I add at the end of the command -lmetis and execute the command
Note that, if I repeat the same operation with metis-5.1.0, it does not work and I have the same error that I wrote in the first post.
I'm trying to build the SDL library from the source code. I've downloaded the compressed file (i.e. SDL2-2.0.3.tar.gz) and extracted it. I don't want to install the files in /usr/local. According to this link, I need to change the configure
The last command says "sudo" so we can write it to /usr/local (by
default). You can change this to a different location with the
--prefix option to the configure script. In fact, there are a LOT of good options you can use with configure! Be sure to check out its
--help option for details.
This is what I've done.
mkdir build
cd build
../configure
make
sudo make install
In install folder that I've created are the following files
share
lib
include
bin
Now I would like to run the test files. I've picked this testatomic.c and this is the command line
gcc testatomic.c -o test -I/home/xxxx/Desktop/SDL2-2.0.3/install/include/SDL2 -L/home/xxxx/Desktop/SDL2-2.0.3/install/lib -lSDL2 -lSDL2main
I get this error
error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
In lib, these are the files
Where is the shared object file?
You're getting error when running resulting program because system's dynamic linker cannot find required library. Program requires libSDL2-2.0.so.0, linker looks for it in system-defined directories (/lib, /usr/lib, ..., - defined in /etc/ld.so.conf), but finds none - hence an error.
To inform linker where you want it to look for libraries, you can define LD_LIBRARY_PATH environment variable, e.g. in your case:
export LD_LIBRARY_PATH="$HOME/Desktop/SDL2-2.0.3/install/lib"
./test
Other ways is installing libraries in standard location, defining LD_LIBRARY_PATH in your .bashrc (or whatever shell you use), or using rpath, e.g. adding -Wl,-rpath=$HOME/Desktop/SDL2-2.0.3/install/lib at the end of your compilation line.
I was able to fix this problem with:
sudo apt install libsdl2-dev
I too had:
./01_hello_SDL: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
as a result of compiling the first C++ program (using the SDL headers) as part of the Lazy Foo tutorial. I found out that libSDL2-2.0.so.0 was just using the find command in the GUI. It turned out to be in /usr/local/lib
Then in terminal I typed:
export LD_LIBRARY_PATH="/usr/local/lib"
I checked the value of LD_LIBRARY_PATH using:
echo $LD_LIBRARY_PATH
I recompiled (don't know if that was necessary) and voila, it worked.
I use gsl.
After I compiled my .cpp file and run it, I faced with below error:
error while loading shared libraries: libgsl.so.0: cannot open shared object file: No such file or directory
I found same as this problem in:
https://groups.google.com/forum/#!topic/cortex_var/6vluX7pP0Sk
&
Linux error while loading shared libraries: cannot open shared object file: No such file or directory
&
http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html
And I have done as in the above links wrote but the error is still remained.
Can anyone help me?
To make it work do the following steps
Start Borne Shell
$LD_LIBRARY_PATH= path to your gsl lib folder inside the gsl installation folder
$export LD_LIBRARY_PATH
now run your executable
It should work fine.
First, you need to locate the file (libgsl.so.0). You can do this, for example, by using the find command:
sudo find / -name "libgsl.so.0"
Let us assume, the file is located in /usr/local/lib.
(If the file has not been found, install the corresponding package or download the source, build it and install it.)
Now, you have two options:
(1) Quick & Dirty:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export LD_LIBRARY_PATH
This adds the path of the library to an environment variable. The disadvantage of this option is, that it is only valid for the current session. It will not work for other users. It will not work once you log off and on again.
(2) Permanent:
Review your /etc/ld.so.conf. If /usr/local/lib is not listed there, add it. Now, run ldconfig to detect the shared object file and add it to some system-wide index.
I got the same error with Krita on Arch Linux. I made a symlink with
ln /usr/lib/libgsl.so /usr/lib/libgsl.so.0
and that fixed it.
In my experience, fastStructure depends on gsl 1.6 but not the latest version.
wget http://gnu.mirror.vexxhost.com/gsl/gsl-1.6.tar.gz
tar -zxvf gsl-1.6.tar.gz
cd gsl-1.16
./configure
make
sudo make install
Add these lines to your .bashrc file on your home directory.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export CFLAGS="-I/usr/local/include"
export LDFLAGS="-L/usr/local/lib"
then, run source ~/.bashrc to set these environment variables.
It works fine when I change the version from the latest to the 1.6.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/shg047/software/gsl/lib/
such as: to-mr: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
Have you tried updating your library? The program I was trying to run simply needed a newer version of gsl (I had 1.9.5 while it needed 2.0.0 or newer).
If you are on arch you can run:
yaourt gsl
and select the appropriate one.
You can use gsl-config --libs in you makefile or in the command line when you link the gsl library. Just type gsl-config you can find the options it offers to you. Choose the options you need, you will find compile and link process much easier than before. As a result, when I type gsl-config --libs in my terminal, I get -L/usr/local/lib -lgsl -lgslcblas -lm. Although it is very simple, first you should know where you gsl is installed. You can add the directory to the PATH environment variable or use the absolute path to execute gsl-config .
I needed libgsl.so.19:
/snap/inkscape/current/bin/inkscape: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
I solved it with:
Installing Anaconda
searched for libgsl.so.19 and found it in ~/anaconda3/lib
run LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/anaconda3/lib (best add it to ~/.basrc)
I'm have built and installed Cyassl-2.4.2 on my unix machine to use with a project of mine; however, when I try to compile my c project, the compiler cannot find the libcyassl.a file. I have searched many times in the Cyassl.2.4.2 folder and am unable to find the file myself. Where is this file locate? Have I missed a step in bulding/installing Cyassl.2.4.2? Thanks!
I had successfully built and installed CyaSSL 2.4.2 here and this is what I got:
~/cyassl$ find . -iname "*.a"
./src/.libs/libcyassl.a
~/cyassl$ ls /usr/local/lib/
libcyassl.a libcyassl.la libcyassl.so libcyassl.so.3 libcyassl.so.3.0.3
The building process used was:
./autogen.sh
./configure
make
sudo make install
The installation prints out:
Libraries have been installed in:
/usr/local/lib
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the -LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to theLD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the LD_RUN_PATH' environment variable
during linking
- use the-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.