I am trying to install this package on ubuntu 18.04. The installation instructions say that the installation command should look like the following:
- autoreconf -i -f
- ./configure --with-libmaus2=${LIBMAUSPREFIX} \
--prefix=${HOME}/biobambam2
- make install
The first line seems to work without any errors. When I try to run the second line like so:
./configure --with-libmaus2=/SOFT/libmaus2-2.0.794-release-20210706224245/ --prefix=/SOFT/biobambam2-2.0.182-release-20210412001032/
I get the following error:
configure: error: Package requirements (libmaus2 >= 2.0.774) were not met:
Package libmaus2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libmaus2.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libmaus2', required by 'world', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables libmaus2_CFLAGS
and libmaus2_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
I understand that ./configure does not see the library directory I provided, but I have no idea how to fix it.
you need to install correctly libmaus2 and set correctly PKG_CONFIG_PATH :
configure and compile libmaus2 this way : ./configure --prefix=/SOFT/libmaus2 && make -j8 install
export PKG_CONFIG_PATH=/SOFT/libmaus2/lib/pkgconfig
./configure --prefix=/SOFT/biobambam2 && make -j8 install
In general, install proper developer version of the library would work.
"Configure" searches the required library with something like:
pkg-config --modversion libmaus2
Typically, Ubuntu distributes two versions: one is the normal lib. The other is a developer version with pc file and header files etc for pkg-config, and with added "-dev" to the pkg name. You can check available library as
apt-cache search libmaus
that returns (on my system Ubuntu 22)
libmaus2-2
libmaus2-dev
If install libmaus2-dev, the pc file named libmaus2.pc would get installed to, for example, /usr/lib/x86_64-linux-gnu/pkgconfig/libmaus2.pc
Install libmaus2 would not get that.
If you have to build libmaus yourself and install to a path not in pkg-config search paths, do something like
export PKG_CONFIG_PATH=/special/path/to/pkgconfig:${PKG_CONFIG_PATH}
NOTE: Use the following to check pkg-config search paths:
pkg-config --variable pc_path pkg-config
Related
I am attempting to cross compile a project for my raspberry pi (32 bit armv8) on my ubuntu machine. I set up a toolchain using crosstool-NG and compiling works, but linking fails. My CMake toolchain file is as follows:
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSROOT /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/sysroot)
SET(CMAKE_C_COMPILER /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/bin/armv8-rpi3-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/bin/armv8-rpi3-linux-gnueabihf-g++)
SET(CMAKE_FIND_ROOT_PATH /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
I have a few libraries that are not being found by the linker. The problem is with my sysroot. I copied over /usr and /lib from the pi to my sysroot folder that was created by crosstool-NG. The libraries that are being linked reside in sysroot/usr/lib/arm-linux-gnueabihf.
However, the linker is not checking that directory, it checks sysroot/usr/lib and a few others, but for some reason it does not check the arm-linux-gnueabihf directory.
On the pi, I can run ld -lasound --verbose and get the following output:
attempt to open //usr/local/lib/arm-linux-gnueabihf/libasound.so failed
attempt to open //usr/local/lib/arm-linux-gnueabihf/libasound.a failed
attempt to open //lib/arm-linux-gnueabihf/libasound.so failed
attempt to open //lib/arm-linux-gnueabihf/libasound.a failed
attempt to open //usr/lib/arm-linux-gnueabihf/libasound.so succeeded
so its finding it correctly on the pi.
When I do the same using the ld generated by crosstool-NG:
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/home/stone/x-tools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/lib/libasound.so failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/home/stone/x-tools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/lib/libasound.a failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/usr/local/lib/libasound.so failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/usr/local/lib/libasound.a failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/lib/libasound.so failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/lib/libasound.a failed
attempt to open /home/stone/development/raspberry_pi/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/bin/../sysroot/usr/lib/libasound.so failed
It fails to find it because it doesnt look in the arm-linux-gnueabihf directory. I copied the library .so file from sysroot/usr/lib/arm-linux-gnueabihf to sysroot/usr/lib and it compiles and links successfully, but I would like to make it so that I do not have to do that. How can I make the linker check that arm-linux-gnueabihf directory?
EDIT: I also copied /etc/ld.so.conf and /etc/ld.so.conf.d from the pi into my sysroot, but it does not seem to affect the linker.
EDIT: After further research it looks like this might be due to something with gcc-multiarch. I am not sure what that is but hopefully I can figure this out
EDIT: I verified that indeed the linker is not searching the arm-linux-gnueabihf path:
./armv8-rpi3-linux-gnueabihf-ld --verbose | grep -i "search"
outputs:
SEARCH_DIR("=/home/stone/x-tools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/lib"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
Alright I got it all figured out. The repo where I learned the tricks to getting this to work can be found here. I am grateful for this repo, without it I would not have gotten this to work.
The issue lies with the linker. The linker that comes with plain old binutils that gets pulled in by crosstool-ng does not search the arm-linux-gnueabihf subdirectories. These directories exist because of Debian multiarch, and in order to get a linker that looks in such a directory, binutils needs to be patched. The instructions that follow assume you have already generated a ct-ng config based on the rpi3 sample.
On the raspberry pi, I installed the binutils-source package:
$ sudo apt install binutils-source
This will give access to a patch file located in /usr/src/binutils/patches.
On the host machine, you need to add a patches directory in the directory where you are building your toolchain (where the ct-ng config file is). It must have a specific structure that reflects the structure of packages in the crosstool-ng repo (ie. inside patches/ you must have a directory with the package name, inside that you must have the version number, and inside that is where you place the patch.):
$ cd your_toolchain_directory
$ mkdir -p patches/binutils/2.31.1/
Now we can copy the patch file from the pi to the host. The specific patch we need is 129_multiarch_libpath.patch:
$ cd patches/binutils/2.31.1/
$ scp pi#raspberrypi:/usr/src/binutils/129_multiarch_libpath.patch
Now that we have the patch, we need to update the config file to tell ct-ng to include local patches as well as enable the multiarch flag for gcc. You can do this using ct-ng menuconfig so change back to the directory with the config file and run:
$ ct-ng menuconfig
In the paths and misc options you need to change the patches origin to bundled then local, and then add ${CT_TOP_DIR}/patches as the local patch directory. This should produce the following lines under the extracting section of the .config file:
CT_PATCH_BUNDLED_LOCAL=y
CT_PATCH_ORDER="bundled,local"
CT_PATCH_USE_LOCAL=y
CT_LOCAL_PATCH_DIR="${CT_TOP_DIR}/patches"
Next you need to add the --enable-multiarch flag in the gcc options. Again using menuconfig, go to the C compiler settings. Add --enable-multiarch to the gcc extra config setting. The config file should have the following in the gcc settings:
CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-multiarch"
Save the config. The last thing we need to do is export a variable.
$ export DEB_TARGET_MULTIARCH=arm-linux-gnueabihf
Now we can build the toolchain:
$ ct-ng build
Once its done, you can change into the bin directory of the generated toolchain and run:
$ ./ld --verbose | grep -i "search"
and you should see that the arm-linux-gnueabihf directory is now in the search paths. What a process.
You need to use static library instead. then the executable will include the binary of the libraries.
But keep in mind the executable file will be bigger ( depends obviously which lib...).
When you using cross compile, you should check that the libraries you use exist in the other environment you execute the program.
The solution will be to add STATIC word according to CmakeList.txt file
In order to install graph-tool, I must install dependencies with autoconf.
Some of these dependencies use boost, and I link my local boost install to these dependencies with:
export BOOST_ROOT=/my/path/boost
./configure
And everything proceeds smoothly. Then, when I shift to graph tool, I get a prompt to add BOOST_ROOT for an "unstaged boost". I don't know what that means, so I try:
export BOOST_ROOT=/my/path/boost
./configure
And this fails. I then inspect graph-tool's configure script, and it seems like, during the test for boost, it checks the following path:
if test -n "$BOOST_ROOT" ; then
for libsubdir in $libsubdirs ; do
if ls "$BOOST_ROOT/stage/$libsubdir/libboost_"* >/dev/null 2>&1 ; then break; fi
done
And I review both my boost install and my boost source code checkout, and I see no paths from the boost root directory with "stage" in them.
This seems strange, given that the dependencies were able to include the local boost install using the autoconfigurer. Are there some simple edits I need to make?
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).
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'm trying to get my Cuda SDK samples running, but I get the following error:
./bandwidthTest: error while loading shared libraries:
libcudart.so.4: cannot open shared object file:
No such file or directory
Why can I compile the example successfully, but not run it? Is there a way to specify the path to the CUDA runtime library manually?
try:
32-bit: sudo ldconfig /usr/local/cuda/lib
64-bit: sudo ldconfig /usr/local/cuda/lib64
cheers
First these that you need is to concatenate the paths to the CUDA binaries and libraries. This is simply done by adding the following lines to your .bashrc file.
export PATH=$PATH:/usr/local/cuda/bin
export LD_LIBRARY_PATH=:/usr/local/cuda/lib64
If you are using a 32-bit operating system change lib64 to lib
Second, there should have been some shared object files installed in /usr/lib or /usr/lib64, depending on your operating system. These object files should be contained in a directory called "nvidia". The two files we are concerned with are names libcuda.so.drivernumber and libOpenCL.so.somenumber. To differentiate between the actual shared object files just use ls -l. The symbolic links will show what they are actually linking to.
As root, execute the following commands:
ln -s /usr/lib64/nvidia/libcuda.so.somenumber /usr/lib64/libcuda.so
ln -s /usr/lib64/nvidia/libOpenCL.so.somenumber /usr/lib64/libOpenCL.so
That should allow you to compile all the sources in the SDK.
As of Cuda 5.5 and Ubuntu 12.04/12.10, the command above becomes (notice the Ubuntu and Cuda directory changes) for 64bit
ln -s /usr/local/cuda/lib64/libcuda.so.5.5 /usr/lib/libcuda.so.5.5
That is, the lib folders on Ubuntu as of 12.04 are lib32 and lib; the 64 is implicit, and cuda 5.5 and greater now installs to a different directory.
1 error while loading shared libraries: libcudart.so.6.0: cannot open shared object file: No such file or directory
32-bit: sudo ldconfig /usr/local/cuda/lib
64-bit: sudo ldconfig /usr/local/cuda/lib64
(refer: http://blog.csdn.net/shenchong721/article/details/21529295)
Works for me!
LD_LIBRARY_PATH is strongly deprecated. It may mess up other programs, and others may reset it. It should only be used to temporarily override the permanent paths for testing purposes (don't take my word, google it).
Instead, add a line with your cuda lib directory on it to /etc/ld.so.conf, after any existing lines.
For example, if you installed on /usr/local/cuda, you will need to add
32-bit : /usr/local/cuda/lib
64-bit : /usr/local/cuda/lib64
Save, and run ldconfig. This should permanently fix the problem.
The symbolic links are probably already set up by the installation. If not, then add them as Alex advised.
Note - I received errors referencing /lib, but I needed to add lib64 to fix them.
create a nvidia_settings.conf file in /etc/ld.so.conf.d/ and add the path to the libs in the file nvidia_settings.conf
/usr/local/cuda/lib64
/usr/local/cuda/lib
Now to update the changes run the following command:
sudo ldconfig
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib
or if you are running cuda-5.0 on a 64-bit machine
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-5.0/lib64
the system find library with ld tool. as the top answer says, 64-bit: sudo ldconfig /usr/local/cuda-xx/lib64 ;;xx is the cuda libraryedition
In my case I was running an application using MPI. The error was:
libcudart.so.7: cannot open shared object file
CUDA was properly installed in all nodes. Also, as in the previous answers, the variables $PATH and $LD_LIBRARY_PATH were pointing to the binary and libraries respectively.
Passing the $PATH and $LD_LIBRARY_PATH in the MPI command solved the issue.
mpirun -x PATH=$PATH -x LD_LIBRARY_PATH=$LD_LIBRARY_PATH ...