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.
Related
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 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'm playing with C++ and tesseract library in mac os. I installed tesseract library with brew install tesseract.
$ tesseract --version
tesseract 3.04.00
leptonica-1.72
libjpeg 8d : libpng 1.6.20 : libtiff 4.0.6 : zlib 1.2.5
I have tesseract installed in following path,
$ ll /usr/local/Cellar/tesseract/3.04.00/
total 72
-rw-r--r-- 1 prayagupd admin 440 Jul 11 2015 AUTHORS
-rw-r--r-- 1 prayagupd admin 1007 Jul 11 2015 COPYING
-rw-r--r-- 1 prayagupd admin 9773 Jul 11 2015 ChangeLog
-rw-r--r-- 1 prayagupd admin 332 Apr 6 19:44 INSTALL_RECEIPT.json
-rw-r--r-- 1 prayagupd admin 45 Jul 11 2015 NEWS
-rw-r--r-- 1 prayagupd admin 6326 Apr 6 19:44 README
drwxr-xr-x 3 prayagupd admin 102 Aug 21 2015 bin
drwxr-xr-x 3 prayagupd admin 102 Aug 21 2015 include
drwxr-xr-x 6 prayagupd admin 204 Aug 21 2015 lib
drwxr-xr-x 4 prayagupd admin 136 Aug 21 2015 share
What I want next is add tesseract lib to a C++ project (which I created with xcode). My assumption was tesseract is available to any c++ project once installed, but I can't see imports in my c++ project. It can't find the file baseapi.h.
I am following example from here - API examples
I feel like I still need to tesseract lib to c++ project in xcode, but don't know how.
Did you try looking under "$ ll /usr/local/Cellar/tesseract/3.04.00/api/" ? At least, it is where I found it on my tesseract folder.
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.