I tried to build this example and got a linkage error:
hekto#ubuntu:~$ g++ -g -Wall -std=c++11 -pthread -DBOOST_LOG_DYN_LINK -pthread sample.cpp -o sample -lboost_log -lboost_thread -lboost_system
/tmp/cc2EUizv.o: In function `boost::log::v2_mt_posix::basic_formatter<char> boost::log::v2_mt_posix::parse_formatter<char>(char const*)':
/usr/include/boost/log/utility/setup/formatter_parser.hpp:207: undefined reference to `boost::log::v2_mt_posix::basic_formatter<char> boost::log::v2_mt_posix::parse_formatter<char>(char const*, char const*)'
collect2: error: ld returned 1 exit status
How to overcome that?
I'm answering my own question, following the #Praetorian help and suggestion.
The Boost Log relies on two libraries (I thought it was only one):
hekto#ubuntu:~$ ls -l /usr/lib/x86_64-linux-gnu/libboost_log*
-rw-r--r-- 1 root root 3510082 Mar 6 2018 /usr/lib/x86_64-linux-gnu/libboost_log.a
-rw-r--r-- 1 root root 2441460 Mar 6 2018 /usr/lib/x86_64-linux-gnu/libboost_log_setup.a
lrwxrwxrwx 1 root root 28 Mar 6 2018 /usr/lib/x86_64-linux-gnu/libboost_log_setup.so -> libboost_log_setup.so.1.65.1
-rw-r--r-- 1 root root 671944 Mar 6 2018 /usr/lib/x86_64-linux-gnu/libboost_log_setup.so.1.65.1
lrwxrwxrwx 1 root root 22 Mar 6 2018 /usr/lib/x86_64-linux-gnu/libboost_log.so -> libboost_log.so.1.65.1
-rw-r--r-- 1 root root 905752 Mar 6 2018 /usr/lib/x86_64-linux-gnu/libboost_log.so.1.65.1
If you compile and link on Linux, you'll have to provide a list of Boost libraries on the command line. According to an answer to this question, given by the main developer (#AndreySemashev) of the Boost Log, these libraries on the command line should look like this:
-lboost_log_setup -lboost_log
Probably it makes sense to provide two libraries instead of one (for example, when you link statically), but I couldn't find any recommendations about when we should use a single library, and when - both of them.
Related
I started working with c++ a few weeks ago, and I started a new project to start learning more. I'm encountering an issue with an external dependency. I'm trying to use a library called:
libbgp, and I installed it base on their documentation.
Here is my code:
https://gist.github.com/amb1s1/9b2c72294da0ec9416810c8686d3adce
Error:
/usr/bin/ld: /tmp/ccsdO32O.o: in function `ticker(libbgp::BgpFsm&)':
ambgp.cpp:(.text+0xa7): undefined reference to `libbgp::BgpFsm::tick()'
collect2: error: ld returned 1 exit status
I'm not sure if there is anything else that I have to do after installing the lib for the library to be accessible in my source code.
Update
I ran it with the -lbgp flag and when running it, i get the following error:
g++ -lbgp ambgp.cpp -o ambgp
Error:
./ambgp: error while loading shared libraries: libbgp.so.0: cannot open shared object file: No such file or directory
My Lib:
ls -l /usr/local/lib/
-rw-r--r-- 1 root root 10875880 Jan 18 16:56 libbgp.a
-rwxr-xr-x 1 root root 924 Jan 18 16:56 libbgp.la
lrwxrwxrwx 1 root root 15 Jan 18 16:56 libbgp.so -> libbgp.so.0.0.0
lrwxrwxrwx 1 root root 15 Jan 18 16:56 libbgp.so.0 -> libbgp.so.0.0.0
-rwxr-xr-x 1 root root 4291128 Jan 18 16:56 libbgp.so.0.0.0
drwxrwsr-x 3 root staff 4096 Dec 16 19:27 python3.7
echo $LD_LIBRARY_PATH
:/usr/local/lib
Before running the executable, you have to tell it where to find the libgdp.so file, if it is not stored in a standard place such as /usr/lib or /lib. Following should help you:
$ export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib"
$ ./ambgp
If you do not want to export the LD_LIBRARY_PATH each time you start the shell manually, add the line to your /home/<user>/.bashrc file.
Additionally, i think the -lbgp flag should go after the source file in the compiler command (g++ ambgp.cpp -lbgp -o ambgp)
TL;DR :
ld states it cannot find libbgp.so.0, and you wrote in the comments that you found libbgp.so without a trailing .0. So, creating a symlink to the library could help too:
$ sudo ln -s /usr/local/lib/libbgp.so /usr/local/lib/libbgp.so.0
For linking, you need a library file without a trailing .0, but for loading, the library name must have a trailing .0.
The last thing to try is to directly specify the library location to the linker with -Wl,-rpath=/usr/local/lib (as you worked out already !)
I have been working in a solution with Oracle database access and C/C++.
I'm using OCCI but we are in trouble to link in Solaris 11.
Solution works "like a charm" in Linux (OpenSUSE and Mint), but doesn't in Solaris 11.
Here environment informations:
I downloaded instantclient_11_2 (sun sparc version) and unpacked it in a Solaris folder
I created symbolic links to libclntsh.so.11.1 called libclntsh.so, and for libocci.so.11.1 called libocci.so. Bellow a "ls -l" showing files:
-rwxrwxr-x 1 f780333 desenv 23792 Aug 22 2013 adrci
-rw-rw-r-- 1 f780333 desenv 414 Aug 22 2013 BASIC_README
-rwxrwxr-x 1 f780333 desenv 41464 Aug 22 2013 genezi
lrwxrwxrwx 1 f780333 desenv 17 Apr 5 14:21 libclntsh.so -> libclntsh.so.11.1
-rwxrwxr-x 1 f780333 desenv 50268448 Aug 22 2013 libclntsh.so.11.1
-r-xr-xr-x 1 f780333 desenv 8653320 Aug 22 2013 libnnz11.so
lrwxrwxrwx 1 f780333 desenv 15 Apr 5 14:22 libocci.so -> libocci.so.11.1
-rwxrwxr-x 1 f780333 desenv 1545008 Aug 22 2013 libocci.so.11.1
-rwxrwxr-x 1 f780333 desenv 118735824 Aug 22 2013 libociei.so
-r-xr-xr-x 1 f780333 desenv 121800 Aug 22 2013 libocijdbc11.so
-r--r--r-- 1 f780333 desenv 2091135 Aug 22 2013 ojdbc5.jar
-r--r--r-- 1 f780333 desenv 2739616 Aug 22 2013 ojdbc6.jar
drwxrwxr-x 4 f780333 desenv 7 Aug 22 2013 sdk
-rwxrwxr-x 1 f780333 desenv 177680 Aug 22 2013 uidrvci
-rw-rw-r-- 1 f780333 desenv 66779 Aug 22 2013 xstreams.jar
I created another folder that contens symbolic links to important needs libraries from Solaris.I am linking project with options -m64 -lCstd -lrt -lsocket. m64 to force 64bits, it was necessary. Cstd, rt and socket due the fact that these libraries are used indirectly.
I am using Netbeans and compile remotely in Solaris 11
Compilation works fine.
Compilation command patterns is showed bellow:
g++ -m64 -c -g -I/home/f780333/paineldaemon/lib/indra_clib/include -I/home/f780333/paineldaemon/lib/instantclient_11_2/sdk/include -std=c++98 -MMD -MP -MF "build/Debug/GNU-Solaris-Sparc/main.o.d" -o build/Debug/GNU-Solaris-Sparc/main.o main.cpp
/home/f780333/paineldaemon/lib/indra_clib/include is a folder with a static library used by program. This library is mine and is necessary for project.
/home/f780333/paineldaemon/lib/instantclient_11_2/sdk/include is a folder from instantclient sdk, that includes *.h from OCCI.
But when linkage process starts, all head pain starts too:
(first) Linkage command:
g++ -o <all files here> -L/home/f780333/paineldaemon/lib/sun -L/home/f780333/paineldaemon/lib -L/home/f780333/paineldaemon/lib/instantclient_11_2 -R'/home/f780333/paineldaemon/lib/sun' -R'/home/f780333/paineldaemon/lib' -R'/home/f780333/paineldaemon/lib/instantclient_11_2' -lclntsh -locci /home/f780333/paineldaemon/lib/libindra_clib.a -m64 -lCstd -lrt -lsocket
And finally the linker ERROR MESSAGE:
Undefined first referenced
symbol in file
oracle::occi::Date::~Date() build/Debug/GNU-Solaris-Sparc/MessageBuilderATM.o
oracle::occi::Date::Date() build/Debug/GNU-Solaris-Sparc/MessageBuilderATM.o
oracle::occi::Number::operator=(oracle::occi::Number const&) build/Debug/GNU-Solaris-Sparc/MessageBuilderATM.o
oracle::occi::Number::Number(double) build/Debug/GNU-Solaris-Sparc/MessageBuilder.o
oracle::occi::Number::Number(long) build/Debug/GNU-Solaris-Sparc/MessageBuilder.o
oracle::occi::Number::Number() build/Debug/GNU-Solaris-Sparc/MessageBuilderATM.o
oracle::occi::Number::~Number() build/Debug/GNU-Solaris-Sparc/MessageBuilderATM.o
oracle::occi::Environment::createEnvironment(oracle::occi::Environment::Mode, void*, void* (*)(void*, unsigned long), void* (*)(void*, void*, unsigned long), void (*)(void*, void*)) build/Debug/GNU-Solaris-Sparc/DatabaseOperation.o
oracle::occi::Date::operator=(oracle::occi::Date const&) build/Debug/GNU-Solaris-Sparc/MessageBuilderATM.o
oracle::occi::Environment::terminateEnvironment(oracle::occi::Environment*) build/Debug/GNU-Solaris-Sparc/DatabaseOperation.o
oracle::occi::Date::Date(oracle::occi::Environment const*, int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) build/Debug/GNU-Solaris-Sparc/MessageBuilder.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
gmake[2]: *** [dist/Debug/GNU-Solaris-Sparc/paineldaemon] Error 1
gmake[2]: Leaving directory `/home/f780333/.netbeans/remote/172.16.160.172/sylvia-Linux-x86_64/home/eduardo/Indra/Cartoes/repo/paineldaemon'
gmake[1]: *** [.build-conf] Error 2
gmake[1]: Leaving directory `/home/f780333/.netbeans/remote/172.16.160.172/sylvia-Linux-x86_64/home/eduardo/Indra/Cartoes/repo/paineldaemon'
gmake: *** [.build-impl] Error 2
I am crazy with this problem, any help will be much apreciate.
In my experience, OCCI has always been built for Solaris by using the Solaris Studio compiler.
You can't link an executable that uses CC-built code using g++, unless you can somehow coerce g++ to link in both the C++ run time libraries libCrun.so and libCstd.so along with the proper C++ run-time startup code, the same as Solaris Studio's CC does. That's probably not impossible, but it would be easier to just invoke ld directly and link the binary yourself.
And you can't compile C++ source code with g++ to match the name-mangling scheme used by Solaris Studio CC. (unless the code was built with a later version of CC and it used command-line arguments to produce g++-compatible name-mangling, among many other compatibility requirements, which in my experience OCCI never has been...)
In short, you need to use Solaris Studio's CC compiler to use OCCI on Solaris.
While compiling few test applications, I get the following error:
g++: error: −lboost_system: No such file or directory
g++: error: −lboost_filesystem: No such file or directory
while running the following command:
g++ -I/usr/include/boost/ -L/usr/lib/x86_64-linux-gnu/ aescuda.cpp -o test.o −lboost_system −lboost_filesystem
The libraries are installed and present in location as shown below:
<prompt>$ ll /usr/lib/x86_64-linux-gnu/libboost_system.*
-rw-r--r-- 1 root root 49178 Jun 20 2014 /usr/lib/x86_64-linux-gnu/libboost_system.a
lrwxrwxrwx 1 root root 25 Jun 20 2014 /usr/lib/x86_64-linux-gnu/libboost_system.so -> libboost_system.so.1.54.0
-rw-r--r-- 1 root root 14536 Jun 20 2014 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0
<prompt>$ ll /usr/lib/x86_64-linux-gnu/libboost_filesystem.*
-rw-r--r-- 1 root root 217628 Jun 20 2014 /usr/lib/x86_64-linux-gnu/libboost_filesystem.a
lrwxrwxrwx 1 root root 29 Jun 20 2014 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so -> libboost_filesystem.so.1.54.0
-rw-r--r-- 1 root root 88936 Jun 20 2014 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0
Can anyone suggest where am I going wrong :(
You have a wrong character in front of the l:
−lboost_system
It should be an ASCII hyphen:
-lboost_system
This causes the compiler driver to treat the whole string as an input file name (which obviously does not exist, hence the No such file or directory error), and not as an option to be passed to the linker.
(Perhaps consider switching the terminal font.)
I am new to using make and I am trying to run the RInside example for Qt density demo given here: http://dirk.eddelbuettel.com/blog/2011/03/25/. I have saved the code into the following files:
main.cpp
Makefile
qtdensity.cpp
include/qtdensity.h
I am running Ubuntu 13.10, I have R, Rcpp and Inside installed. When I go to the terminal and run
> make -f Makefile
I get the error
make: *** No targets. Stop.
Please let me know how to proceed.
Thank you
I can't see how to ask a follow up to the first answer so I have to extend my question:
I have just created the files and was able to run qmake on main.cpp, qtdensity.cpp, qtdensity.h, and qtdensity.pro which worked but when I tried to run make, I get the following errors:
Lots of R - related errors ...
qtdensity.cpp:(.text+0x53a): undefined reference to `Rf_mkString'
qtdensity.cpp:(.text+0x54e): undefined reference to `Rf_install'
qtdensity.cpp:(.text+0x559): undefined reference to `Rf_findVarInFrame'
qtdensity.cpp:(.text+0x560): undefined reference to `R_UnboundValue'
...
qtdensity.cpp:(.text.startup+0x2a5): undefined reference to `R_NaReal'
qtdensity.cpp:(.text.startup+0x2b2): undefined reference to `R_NaN'
main.o: In function `_GLOBAL__sub_I_main':
main.cpp:(.text.startup+0x2a5): undefined reference to `R_NaReal'
main.cpp:(.text.startup+0x2b2): undefined reference to `R_NaN'
main.o: In function `main':
main.cpp:(.text.startup+0x352): undefined reference to `RInside::RInside(int, char const* const*, bool, bool, bool)'
main.cpp:(.text.startup+0x397): undefined reference to `RInside::~RInside()'
main.cpp:(.text.startup+0x3b3): undefined reference to `RInside::~RInside()'
moc_qtdensity.o: In function `_GLOBAL__sub_I__ZN9QtDensity18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv':
moc_qtdensity.cpp:(.text.startup+0x2a5): undefined reference to `R_NaReal'
moc_qtdensity.cpp:(.text.startup+0x2b2): undefined reference to `R_NaN'
collect2: error: ld returned 1 exit status
make: *** [qdensity] Error 1
The Qt example is different because it uses Qt. You always need to start by creating the Makefile itself from the .pro file. Witness:
edd#max:~/git/rinside/inst/examples/qt$ ls -l ## no Makefile
total 28
drwxrwxr-x 2 edd edd 4096 Dec 27 18:38 cmake
-rw-rw-r-- 1 edd edd 518 Dec 27 18:38 main.cpp
-rw-rw-r-- 1 edd edd 5953 Dec 27 18:38 qtdensity.cpp
-rw-rw-r-- 1 edd edd 1532 Dec 27 18:38 qtdensity.h
-rw-rw-r-- 1 edd edd 2378 Feb 11 20:14 qtdensity.pro
-rw-rw-r-- 1 edd edd 887 Dec 27 18:38 README
edd#max:~/git/rinside/inst/examples/qt$ qmake ## creates Makefile
edd#max:~/git/rinside/inst/examples/qt$ make
g++ -c -m64 -pipe -I/usr/share/R/include [... lots and lots omitted ...]
g++ -m64 -Wl,-O1 -o qtdensity qtdensity.o main.o moc_qtdensity.o [....]
edd#max:~/git/rinside/inst/examples/qt$ ls -l qtdensity
-rwxrwxr-x 1 edd edd 76666 Feb 14 15:02 qtdensity
edd#max:~/git/rinside/inst/examples/qt$
This is of course also described in the README in this directory...
The link step gets undefined references for all my mysql calls:
~/private/WDI/git$ make
c++ -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -lrt -ldl -o tom tom.o Block.o IPC.o ConnectMxctl.o CI_Metadata.o Log.o
tom.o: In function `connect_to_table_managers()':
/home/chap/private/WDI/git/tom.cpp:128: undefined reference to `mysql_num_rows'
/home/chap/private/WDI/git/tom.cpp:132: undefined reference to `mysql_num_fields'
/home/chap/private/WDI/git/tom.cpp:133: undefined reference to `mysql_fetch_row'
/home/chap/private/WDI/git/tom.cpp:153: undefined reference to `mysql_num_rows'
/home/chap/private/WDI/git/tom.cpp:157: undefined reference to `mysql_fetch_row'
/home/chap/private/WDI/git/tom.cpp:167: undefined reference to `mysql_free_result'
The link libraries in the c++ command were generated by mysql_config --libs. Here's a partial listing of the directory:
/usr/lib/x86_64-linux-gnu$ ll libmysql*
-rw-r--r-- 1 root root 4838468 Jul 23 23:28 libmysqlclient.a
lrwxrwxrwx 1 root root 16 Jul 23 23:28 libmysqlclient_r.a -> libmysqlclient.a
lrwxrwxrwx 1 root root 17 Jul 23 23:28 libmysqlclient_r.so -> libmysqlclient.so
lrwxrwxrwx 1 root root 20 Jul 23 23:28 libmysqlclient_r.so.18 -> libmysqlclient.so.18
lrwxrwxrwx 1 root root 24 Jul 23 23:28 libmysqlclient_r.so.18.0.0 -> libmysqlclient.so.18.0.0
lrwxrwxrwx 1 root root 20 Jul 23 23:28 libmysqlclient.so -> libmysqlclient.so.18
lrwxrwxrwx 1 root root 24 Jul 23 23:28 libmysqlclient.so.18 -> libmysqlclient.so.18.0.0
-rw-r--r-- 1 root root 3408144 Jul 23 23:28 libmysqlclient.so.18.0.0
So things appear to be in their proper places. Why would these symbols be unresolvable?
You should put most independent library in the end of the command, so compiler can find symbol and definitions properly:
c++ -L/usr/lib/x86_64-linux-gnu -o tom tom.o Block.o IPC.o \
ConnectMxctl.o CI_Metadata.o Log.o \
-lmysqlclient -lpthread -lz -lm -lrt -ldl
By doing it this way, compiler will continue searching undefined symbols from next linking files. For exampile if IPO.o has uses symbol(type/class/struct/function etc) defined in CI_Metadata.o, compiler can find it because you put CI_Metadata.o after IPO.o. Most libraries are independent, that's why they are in the end of compile/link command.