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.
Related
Linux programmer here. I've installed some libraries such as Intell TBB on my Mac and am using Visual Studio Code to compile a source file that uses them:
#include "tbb/tbb.h"
#include "tbb/mutex.h"
But I get an error that these headers can't be found. Where are they installed and how can I tell VSC where to look for them.
Also is linking the same as in Linux?
If you installed using homebrew (which is generally a good idea since Apple doesn't provide any package management tools), you can see what files were installed where using:
brew ls tbb
Sample Output
/usr/local/Cellar/tbb/2018_U5/include/tbb/ (109 files)
/usr/local/Cellar/tbb/2018_U5/lib/libtbb.dylib
/usr/local/Cellar/tbb/2018_U5/lib/libtbbmalloc.dylib
/usr/local/Cellar/tbb/2018_U5/lib/libtbbmalloc_proxy.dylib
/usr/local/Cellar/tbb/2018_U5/lib/cmake/ (2 files)
/usr/local/Cellar/tbb/2018_U5/lib/python2.7/ (11 files)
/usr/local/Cellar/tbb/2018_U5/lib/ (2 other files)
Sometimes it only tells you half the story, so use:
brew ls --verbose tbb
It generally links all includes and libraries into /usr/local too, so use:
ls -l /usr/local/{include,lib} | grep tbb
Sample Output
lrwxr-xr-x 1 mark admin 33 Sep 17 2018 tbb -> ../Cellar/tbb/2018_U5/include/tbb
lrwxr-xr-x 1 mark admin 34 Sep 17 2018 libtbb.a -> ../Cellar/tbb/2018_U5/lib/libtbb.a
lrwxr-xr-x 1 mark admin 38 Sep 17 2018 libtbb.dylib -> ../Cellar/tbb/2018_U5/lib/libtbb.dylib
lrwxr-xr-x 1 mark admin 40 Sep 17 2018 libtbbmalloc.a -> ../Cellar/tbb/2018_U5/lib/libtbbmalloc.a
lrwxr-xr-x 1 mark admin 44 Sep 17 2018 libtbbmalloc.dylib -> ../Cellar/tbb/2018_U5/lib/libtbbmalloc.dylib
lrwxr-xr-x 1 mark admin 50 Sep 17 2018 libtbbmalloc_proxy.dylib -> ../Cellar/tbb/2018_U5/lib/libtbbmalloc_proxy.dylib
They are installed where you installed TBB. Usually, that's in /opt/intel if you used Intel packages. Just like on Linux.
I successfully build and installed kdev-control-flow-graph plugin after forking from sandsmark/kdev-control-flow-graph into my own fljx/kdev-control-flow-graph branch with minimal changes.
When I try to enable kdev-control-flow-graph view, though, I receive the error below:
"Unable to create a KGraphViewer instance, please verify that a compatible version is installed."
I am running on Kubuntu 16.04 with KDevelop 5.1.1 and kgraphviewer is installed:
# apt search kgraphviewer
Sorting... Pronto
Full Text Search... Pronto
kgraphviewer/xenial,now 4:2.1.90-0ubuntu2 amd64 [installed]
GraphViz dot graph viewer
kgraphviewer-dbg/xenial 4:2.1.90-0ubuntu2 amd64
GraphViz dot graph viewer for KDE 4 debug files
kgraphviewer-dev/xenial,now 4:2.1.90-0ubuntu2 amd64 [installed]
GraphViz dot graph viewer - devel files
libkgraphviewer2/xenial,now 4:2.1.90-0ubuntu2 amd64 [installed]
GraphViz dot graph viewer - libs
Then I build KGraphViewer from github and my system now has:
# find /usr -iname "*kgraphviewer*.so*" -ls
10571222 0 lrwxrwxrwx 1 root root 22 Ago 14 2015 /usr/lib/libkgraphviewer.so.2 -> libkgraphviewer.so.2.1
10571221 712 -rw-r--r-- 1 root root 728288 Ago 14 2015 /usr/lib/libkgraphviewer.so.2.1
10558158 2868 -rw-r--r-- 1 root root 2935024 Ago 17 16:32 /usr/lib/x86_64-linux-gnu/libkgraphviewer.so.3
11170876 0 lrwxrwxrwx 1 root root 57 Ago 17 16:37 /usr/lib/x86_64-linux-gnu/qt5/plugins/kdevplatform/27/kgraphviewerpart.so -> /usr/lib/x86_64-linux-gnu/qt5/plugins/kgraphviewerpart.so
10748549 180 -rw-r--r-- 1 root root 181312 Ago 17 16:32 /usr/lib/x86_64-linux-gnu/qt5/plugins/kgraphviewerpart.so
10558159 0 lrwxrwxrwx 1 root root 20 Ago 17 16:33 /usr/lib/x86_64-linux-gnu/libkgraphviewer.so -> libkgraphviewer.so.3
10571223 60 -rw-r--r-- 1 root root 60392 Ago 14 2015 /usr/lib/kde4/kgraphviewerpart.so
10571224 0 lrwxrwxrwx 1 root root 20 Ago 14 2015 /usr/lib/libkgraphviewer.so -> libkgraphviewer.so.2
Could anybody please give me any hints on how to make my plugin correctly find KGraphViewer KPart?
Thanks in advance.
KDE dev reporting in.
KGraphViewer is embedded into other applications using KParts framework. Porting KGraphViewer's KPart to Qt5/KF5 is near to release. The bad news is that kdev-control-flow-graph don't work with new KGraphViewer, so this plugin needs to be updated too.
Suppose I have an executable that uses qt library. I want to replace the shared object with a custom one. So how do I find the qt version so that I can build it myself from source?
P.S. All the files has names like libQt5**.so.5.
If you don't own a very special setup the exact version is part of the lib name; all others are symlinks. E. g. installed here is Qt 4.8.1:
$ ls -l /usr/lib/i386-linux-gnu/libQtCore.*
-rw-r--r-- 1 root root 680 Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.prl
lrwxrwxrwx 1 root root 18 Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.so -> libQtCore.so.4.8.1
lrwxrwxrwx 1 root root 18 Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.so.4 -> libQtCore.so.4.8.1
lrwxrwxrwx 1 root root 18 Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.so.4.8 -> libQtCore.so.4.8.1
-rw-r--r-- 1 root root 2,9M Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.so.4.8.1
Additionally the libs provide macros and functions to access the version at build and run time: QT_VERSION, QT_VERSION_STR and qVersion().
I am trying to run a sample executable provided with Xalan C++ library, which requires a the Xerces C library. But I am not able to properly link the Xerces shared object file.
mike#ubuntu:~/Xalan-C_1_9_0-redhat_80-gcc_32/bin$ ldd SimpleXPathAPI
linux-gate.so.1 => (0xf7765000)
libxalan-c.so.19 => /home/mike/Xalan-C_1_9_0-redhat_80-gcc_32/lib/libxalan-c.so.19 (0xf7409000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf73ab000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf738e000)
libxerces-c.so.26 => not found
libxalanMsg.so.19 => /home/mike/Xalan-C_1_9_0-redhat_80-gcc_32/lib/libxalanMsg.so.19 (0xf7386000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf71d8000)
/lib/ld-linux.so.2 (0xf7768000)
libstdc++.so.5 => not found
libxerces-c.so.26 => not found
I included the location containing the libxerces-c.so in my LD_LIBRARY_PATH but ldd will not find it.
mike#ubuntu:~/Xalan-C_1_9_0-redhat_80-gcc_32/bin$ echo $LD_LIBRARY_PATH
/home/mike/Xalan-C_1_9_0-redhat_80-gcc_32/lib:/usr/local/lib
I even added a soft link to ensure the .26 is included.
mike#ubuntu:/usr/local/lib$ ls -l
total 98308
-rwxr-xr-x 1 root root 25560971 Aug 28 13:39 libxerces-c-3.1.so
-rw-r--r-- 1 root root 75080734 Aug 28 13:39 libxerces-c.a
-rwxr-xr-x 1 root root 962 Aug 28 13:39 libxerces-c.la
lrwxrwxrwx 1 root root 18 Aug 28 13:39 libxerces-c.so -> libxerces-c-3.1.so
lrwxrwxrwx 1 root root 14 Oct 21 10:31 libxerces-c.so.26 -> libxerces-c.so
drwxr-xr-x 2 root root 4096 Aug 28 13:39 pkgconfig
drwxrwsr-x 4 root staff 4096 Feb 18 2015 python2.7
drwxrwsr-x 3 root staff 4096 Feb 18 2015 python3.4
drwxr-xr-x 3 root root 4096 Jul 6 15:42 site_ruby
The first time I had this => not found issue with libxalan-c.so.19 I solved it by adding the location of that file to my LD_LIBRARY_PATH. So I can't figure out why the same fix is not working for the libxerces-c.so.26. Does anyone know what I'm doing wrong?
What does this produce:
cd /usr/local/lib
file -L ./libxerces-c.so.26
Chances are, this will print something like ELF 64-bit LSB shared object ..., in which case you are trying to point 32-bit executable at 64-bit libraries, and that doesn't work.
You need to download a 32-bit build of libxerces.
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.