I have install this driver for a long time, but failed. There is some failed infomation as following
# scons
Reading SConscript files ...
Checking for C++ library boost_thread-mt... no
Checking for C++ library boost_thread... no
# echo $LD_LIBRARY_PATH
/usr/lib:/usr/local/lib/:/usr/local/mpc/lib:/usr/local/gmp/lib:/usr/local/mpfr/lib/
# ls /usr/local/lib/libboost_thread* -l
-rw-r--r-- 1 root root 288364 Dec 28 18:16 /usr/local/lib/libboost_thread.a
lrwxrwxrwx 1 root root 40 Jan 1 13:05 /usr/local/lib/libboost_thread-mt.so -> /usr/local/lib/libboost_thread.so.1.52.0
lrwxrwxrwx 1 root root 25 Dec 28 18:10 /usr/local/lib/libboost_thread.so -> libboost_thread.so.1.52.0
-rwxr-xr-x 1 root root 186164 Dec 28 18:10 /usr/local/lib/libboost_thread.so.1.52.0
I have installed the boost v1.52, scons v2.2.0, and I want to install the mongodb C++ driver v2.2. Any Ideas? thanks very much.
The LD_LIBRARY_PATH environment variable affects where libraries are located at runtime, not at link time. The client driver SConstruct file provides an option --extrapath, which allows you to provide additional library search paths.
Try running:
scons --extrapath=/usr/local
to see if it will pick up boost libraries that you have installed in /usr/local.
Related
I noticed these lines in my cpp file did not work if I tried to use opencv binaries versus building from source:
#include <opencv2/core.hpp>
#include <opencv2/aruco/charuco.hpp>
Is there a way to make this work without building from source? Building from source is very slow, and especially when I am using docker files this is problematic (yes, I know docker builds are usually cached, but when you have to break the cache, the opencv build adds a lot of slow down).
Yes. If you are in a distro like Ubuntu, you can just install the development package for that library with
$ sudo apt install libopencv-dev
or on Redhat/EPEL
$ sudo yum install libopencv-devel
Your headers will be installed inside /usr
$ find /usr -name 'opencv.hpp'
/usr/include/opencv4/opencv2/opencv.hpp
/usr/include/boost/compute/interop/opencv.hpp
as well as the cmake modules (for find_package)
$ ls /usr/lib/x86_64-linux-gnu/cmake/opencv4/ -l
total 64
-rw-r--r-- 1 root root 14222 Feb 17 2020 OpenCVConfig.cmake
-rw-r--r-- 1 root root 418 Feb 17 2020 OpenCVConfig-version.cmake
-rw-r--r-- 1 root root 15428 Feb 17 2020 OpenCVModules.cmake
-rw-r--r-- 1 root root 26215 Feb 17 2020 OpenCVModules-release.cmake
Within docker that's usually a line in Dockerfile (as root before switching to the end user)
RUN apt install -y libopencv-dev
I want to compile (c++/cmake) code using boost 1.69. I am on centos 7.
After :
sudo yum install boost-devel.x86.64
the code compiles fine, but using the default version which is 1.53.
If I look at the libraries installed in /lib64, I see for example:
>> ls -al /lib64/ | grep boost_timer
lrwxrwxrwx. 1 root root 27 Jun 9 11:50 libboost_timer-mt.so -> libboost_timer-mt.so.1.53.0
-rwxr-xr-x. 1 root root 19848 Apr 1 04:26 libboost_timer-mt.so.1.53.0
The yum installation for boost 1.69 is also available. So I can do:
sudo yum install boost169-devel.x86_64
which updates for example the content of /lib64/
>> ls -al /lib64/ | grep boost_timer
lrwxrwxrwx. 1 root root 27 Jun 9 11:50 libboost_timer-mt.so -> libboost_timer-mt.so.1.53.0
-rwxr-xr-x. 1 root root 19848 Apr 1 04:26 libboost_timer-mt.so.1.53.0
lrwxrwxrwx. 1 root root 24 Jun 9 11:50 libboost_timer.so -> libboost_timer.so.1.53.0
-rwxr-xr-x. 1 root root 19848 Apr 1 04:26 libboost_timer.so.1.53.0
-rwxr-xr-x. 1 root root 24104 Apr 23 2019 libboost_timer.so.1.69.0
also :
>> ls /usr/include/ | grep boost
boost
boost169
At this point my workspace still compiles, but still using 1.53.
I would like my workspace to compile using 1.69. I could achieve this by botching
FindBoost.cmake but this does not feel like the clean thing to do.
Also I tried (yum) removed boost-dev.x86-64, which removed the folder /usr/include/boost and the related so files in /lib64, which leaves for example:
>> ls -al /lib64/ | grep boost_timer
libboost_timer-mt.so.1.53.0
libboost_timer.so.1.53.0
libboost_timer.so.1.69.0
(note that there is no longer a "libboost_timer-mt.so")
At this point I believe I could also get my workspace to compile by manually creating symbolic links /usr/include/boost and /lib64/libboost_*.so , but that does also not feel like the clean thing to do
(note: I created the symbolic link /usr/include/boost pointing to /usr/include/boost64/boost, and indeed cmake stopped complaining about BOOST_INCLUDE_DIR, but because I did not create the symbolic links for the libraries, cmake still complains about those).
Is there a cleaner alternative way to manual creation of symbolic links ?
edit : I did create manually symbolic links for all the boost related libraries the compiler was complaining about, and I can confirm this worked.
So there's obviously BOOST_INCLUDE_DIR which you can use to control where boost headers, so why not just
cmake -DBOOST_INCLUDEDIR=/usr/include/boost169 \
-DBOOST_LIBRARYDIR=/usr/lib64/boost169 \
...
The closest you can get to setting the default for CMake is to set BOOST_INCLUDEDIR and BOOST_LIBRARYDIR as environment variables. FindBoost.cmake explicitly looks for those variables in the environment (something CMake does not do by default). So you can globally export BOOST_INCLUDEDIR=/usr/include/boost169 and export BOOST_LIBRARYDIR=/usr/lib64/boost169 somewhere, or you can also wrap command invocations with, e.g., BOOST_INCLUDEDIR=/usr/include/boost169 BOOST_LIBRARYDIR=/usr/lib64/boost169 ./mybuild.sh (assuming that mybuild.sh ends up invoking CMake or handles those environment variables itself, of course).
I've ran the following command to list the openssl library files on disk:
apt-file list libssl-dev
And got the output:
(a long list of *.h files)
libssl-dev: /usr/lib/x86_64-linux-gnu/libcrypto.a
libssl-dev: /usr/lib/x86_64-linux-gnu/libcrypto.so
libssl-dev: /usr/lib/x86_64-linux-gnu/libssl.a
libssl-dev: /usr/lib/x86_64-linux-gnu/libssl.so
(.pc, .gz and others)
But the libssl.a and libssl.so arn't on the disk.
ls -l /usr/lib/x86_64-linux-gnu/libssl*
Gives this output:
-rw-r--r-- 1 root root 328128 Feb 5 2018 /usr/lib/x86_64-linux-gnu/libssl3.so
-rw-r--r-- 1 root root 426232 Jun 20 05:00 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
-rw-r--r-- 1 root root 433760 Jun 20 04:29 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
So how do I link to the ssl library in my C++ applications? When I specify -llibssl.so, I get an error telling me its not found.
If I'm supposed to pick one of the existing files on disk, which one do I pick and what criteria do I use?
I'm using Ubuntu 18.04.
Just install the develop package sudo apt install libssl-dev
I downloaded and extracted amplide-demo-linux64.tar.gz to /opt/amplide/.
Then I downloaded lp_solve_5.5.2.0_exe_ux32.tar.gz and extracted file lpsolve to /opt/amplide/ampl/.
And I have liblpsolve55.so under directory suggested on AMPL page:
kjrz#kjrz-tsh ~ $ ll /usr/lib/lp_solve/
total 604
drwxr-xr-x 2 root root 4096 Jun 24 2014 .
drwxr-xr-x 185 root root 20480 Jan 14 11:11 ..
-rw-r--r-- 1 root root 590168 Dec 23 2013 liblpsolve55.so
This is what happens:
ampl: option solver lpsolve;
ampl: model owd.mod;
ampl: data owd.dat;
ampl: solve;
lpsolve: error while loading shared libraries: liblpsolve55.so: cannot open shared object file: No such file or directory
exit code 127
<BREAK>
How is that?
You should put (a link to) the liblpsolve55.so somewhere on the library search paths, for example /usr/lib:
$ sudo ln -s /usr/lib/lp_solve/liblpsolve55.so /usr/lib
Also make sure that you have 32-bit (x86) version of liblpsolve55.so installed. For example, on 64-bit Ubuntu you can install 32-bit version of liblpsolve55.so as follows:
$ sudo apt-get install lp-solve:i386
I am linking an application with mysqlclient library on 64-bit CentOS 5.4 and get a linkage error (cannot find -lmysqlclient).
The library is in /usr/lib64/mysql/:
una#localhost$ ll /usr/lib64/mysql/
total 9072
...
lrwxrwxrwx 1 root root 26 Jan 3 15:54 libmysqlclient_r.so -> libmysqlclient_r.so.15.0.0
lrwxrwxrwx 1 root root 26 Jan 3 15:54 libmysqlclient_r.so.15 -> libmysqlclient_r.so.15.0.0
-rwxr-xr-x 1 root root 1518456 Sep 4 01:28 libmysqlclient_r.so.15.0.0
lrwxrwxrwx 1 root root 24 Jan 3 15:54 libmysqlclient.so -> libmysqlclient.so.15.0.0
lrwxrwxrwx 1 root root 24 Jan 3 15:54 libmysqlclient.so.15 -> libmysqlclient.so.15.0.0
-rwxr-xr-x 1 root root 1514000 Sep 4 01:28 libmysqlclient.so.15.0.0
...
And the directory seems to be properly registered for Linux linker:
una#localhost$ cat /etc/ld.so.conf.d/mysql-x86_64.conf
/usr/lib64/mysql
The only way I can link the application on this machine is by specifying the full path to the library file which is unacceptable in my case.
What could cause the problem here?
Thanks.
-L/usr/lib64/mysql
The ld.so.conf stuff is only used at runtime, not compile time.
/usr/lib64/mysql is certainly not in your gcc's default search path. You may use a autoconf script to search for the installation path of libmysqlclient on this kind of a distribution, and dynamically use the found location with the -L flag.