I'm trying to build a boost-dependent project on TravisCI. When it runs the g++ command:
g++ -Wall -L/usr/lib -fopenmp -lboost_system -lboost_filesystem -o bin/test obj/data_parser.o obj/hmm.o obj/test.o
It gets this linking error:
data_parser.cpp:(.text+0x136a): undefined reference to `boost::system::generic_category()'
But not only am I including -lboost_system in the g++ command, I also know that /usr/lib/libboost_system.so exists.
This is on an Ubuntu/Linaro 4.6.3-1ubuntu5 system with g++ 4.6.3. I installed the boost libraries with:
sudo apt-get install libboost-dev libboost-filesystem1.46-dev libboost-iostreams1.46-dev libboost-system1.46-dev
Why won't this link correctly?
Put the libraries after the object files in the linker command.
The objects and libraries are linked in order; and library code is only linked if it's needed to resolve a reference in the currently linked objects. By putting them first, there are no unresolved references when they are processed, so no code is linked from them.
Related
I found a lot of similar problems, but I was not able to apply any given solution for me. A few months ago, I worked on a project using the boost library. I compiled simply in the command line, as described on the boost website.
g++ -I pathToBoost file.cpp -o file -lboost_system -lboost_filesystem
The two required linkings to boost_system and boost_filesystem were also done. This worked perfectly, but now suddenly an error occurs when i tried to compile it again.
/usr/bin/ld: /tmp/ccM2BzEo.o: in function `boost::system::generic_category()':
file.cpp:(.text._ZN5boost6system16generic_categoryEv[_ZN5boost6system16generic_categoryEv]+0x7):
undefined reference to `boost::system::detail::generic_category_instance'
Well, it seems to me that there is an error linking the boost_system library. Since the same thing worked before, is a problem with the compiler possible?
I used
Boost 1.68.0
g++ (GCC) 8.2.1
ManjaroLinux 18.0.3
I hope that somebody can help me here and that I was not just too stupid to see a solution in another thread.
Greetings!
The order of libraries in linker command line is important. boost_filesystem depends on boost_system, hence the fix:
-lboost_filesystem -lboost_system
Alternatively, you can surround the list of libraries with --start-group and --end-group to make the linker re-scan the libraries multiple times until it either fails or resolves all symbols, so that no specific ordering of libraries in the command line is necessary. However, it may take longer to link. E.g.:
g++ -I pathToBoost file.cpp -o file -Wl,--start-group -lboost_system -lboost_filesystem -Wl,--end-group
Since you specify -I pathToBoost you also need to specify -L<path-to-boost-libs> -Wl,-rpath=<path-to-boost-libs>. Otherwise it uses headers from one version of boost from pathToBoost, but links wrong libraries from your system boost.
there are some files that I am trying to compile in ubuntu using makefile.
I have added the following lines in my makefile after several searches on web.
run: hellocode.cpp
g++ -c hellocode.cpp -lssl -lcrypto
Still while compiling it creates the object files and then throws this error:
undefined reference to 'SSL_write'....
on the contrary if remove the '-c' and use it like this
run: hellocode.cpp
g++ hellocode.cpp -lssl -lcrypto
Then I dont see the previous errors of linking but it shows different errors not related to openssl linking but related to other files in the code. I have already browsed through many questions on this forum related to this none seem to have helped me in this.
Kindly tell me whether my makefile is wrong or is there some problem with my machine that its not able to link to my library.
Here's a simple Makefile that you could adopt. Note that compilation and linking are 2 steps. If needed you can use -I for additional include paths and -L for additional link paths.
.PHONY : all
all : hellocode
hellocode : hellocode.o
g++ -o hellocode hellocode.o -lssl -lcrypto
hellocode.o : hellocode.cpp
g++ -c hellocode.cpp -o hellocode.o
Here are some basics of makefiles if it helps.
library linking should be done at final stage - linking :)
-c means "compile only" - it just builds .o object file, without any reference resolution (so -lXXX is just ignored there).
-lXXX options should be added to last call to gcc (without -c) which produces executable, where all .o files are gathered to link together with libraries to resolve all references.
I'm trying to use X86_64-w64-mingw32-g++ (packaged in Archlinux's MingW package) to cross compile some C++ code into an Windows executable, however I'm having trouble getting past some issues.
I'm calling
x86_64-w64-mingw32-g++ -o build_win/asm build_win/asm.o build_win/asm_lib.o build_win/socket_boost.o -I../extra/etc -fopenmp -lrt -std=c++11 -g -lboost_system -lboost_serialization
from a makefile, but I get thrown the errors:
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lrt
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lboost_system
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lboost_serialization
This works fine with native g++, so exactly do I have to change for mingw to compile?
EDIT: I have mingw-w64-boost package installed, which includes boost libraries pre-compiled and ready to be linked. However, it seems the naming convention is a bit different, and -lboost_system for example becomes -llibboost_system-mt (not exactly sure what the -mt suffix entails).
Problem is I can't find the mingw counterpart for -lrt. I've tried with both -lrtm and -lrtutils but in both cases I get:
[...]
undefined reference to `__imp_getsockopt'
Are you sure that -lboost_system and other libraries are present in the same directory as makefile ?
If not then please include -L flag which indicates the location of your library.
For example:
-L /path_openmp -fopenmp -L /path_boost_system/ -lboost_system -L /path_serialization -lboost_serialization
Moreover, you need not include -I and -g flag when creating an executable from .o files. These are needed when you create .o from .cpp files.
There is no rt library on Windows.
You are missing -lws2_32.
$ x86_64-w64-mingw32-nm -A /usr/x86_64-w64-mingw32/lib/*.a 2>/dev/null | grep getsockopt | grep " T "
I am trying to build an image processing program written in C++ that depends on the following libraries using MinGW + MSYS (with GCC4.8.1) that I downloaded from www.mingw.org/ on a Windows 8 64bit computer
LibJPEG
BLAS and LAPACK
Armadillo
OpenMP
I have successfully compiled all the source code files (with -fopenmp flag of course), then I linked with the following statement:
g++ -o ./build/rspfitter {a list of .o files}
-L{paths to libraries} -ljpeg -lopenblas -lgomp -lpthread
The executable was correctly produced. However, it asks for the following dlls:
libgomp-1.dll
libpthread-2.dll
pthreadGC2.dll
I think it might a better idea to link libgomp and libpthread statically, so that I can minimize the number of dlls I need to deploy my program with (the above three dlls are not the only ones the program depends on). So I tried to link only libgomp and libpthread statically with the following command:
g++ -o ./build/rspfitter {a list of .o files}
-L{paths to libraries} -ljpeg -lopenblas -Wl,-static -lgomp -lpthread
But this time it fails with the following error message:
d:/mingw/bin/../lib/gcc/mingw32/4.8.1\libgomp.a(env.o):(.text.startup+0xbfe):
undefined reference to `_imp__pthread_attr_init'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1\libgomp.a(env.o):(.text.startup+0xc13):
undefined reference to `_imp__pthread_attr_setdetachstate'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1\libgomp.a(env.o):(.text.startup+0x3c):
undefined reference to `_imp__pthread_attr_setstacksize'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
d:/mingw/bin/../lib/gcc/mingw32/4.8.1\libgomp.a(env.o): bad reloc
address 0x0 in section `.ctors'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
final link failed: Invalid operation
Then I tried to execute the exact same compiling and linking commands using the MinGW + GCC 4.8.1 environment that was installed together with CodeLite. It fails again with different error messages：
./tmp/hshfitcmdline.o:hshfitcmdline.cpp:(.text.unlikely+0x105):
undefined reference to `_Unwind_Resume'
./tmp/hshfitcmdline.o:hshfitcmdline.cpp:(.text$_ZN9NormalMapD1Ev[__ZN9NormalMapD1Ev]+0xb4):
undefined reference to `_Unwind_Resume'
d:/mingw-4.8.1/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
./tmp/hshfitcmdline.o: bad reloc address 0xb4 in section
`.text$_ZN9NormalMapD1Ev[__ZN9NormalMapD1Ev]'
d:/mingw-4.8.1/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
final link failed: Invalid operation collect2.exe: error: ld returned
1 exit status make: *** [build/rspfitter] Error 1
I confirmed that the file "libgomp.a"/"libgomp.dll.a" was present on the [MinGW dir]/lib/gcc/mingw32/4.8.1/ for both installations of MinGW. However, they are of different sizes! In installation downloaded from MinGW.org, 'libgomp.a' is of 86kb, and "libgomp.dll.a" is of 87kb; In the CodeLite installation, however, the sizes are 74kB and 148Kb respectively.
Now I am wondering:
What could be the cause of the error messages given by the two MinGW systems? Could it be that the statically libraries that I downloaded from MinGW are corrputed? But dynamically linking was perfectly fine on both systems.
How on earth can I correctly link libgomp statically?
Thanks
To link libgomp statically you can do
ln -s `g++ --print-file-name=libgomp.a` && \
g++ foo.o -static-libgcc -static-libstdc++ -L. -o foo -fopenmp -ljpeg -lopenblas
However your executable will still depend on a pthread dll. The reason you are getting the error is that libc is still linking dynamically. To fix this you have to link libc statically as well
ln -s `g++ --print-file-name=libpthread.a` && \
ln -s `g++ --print-file-name=libc.a` && \
g++ foo.o -static-libgcc -static-libstdc++ -L. -o foo -fopenmp -ljpeg -lopenblas
However, if openblas or jpeg libraries depend on libc then there will likely still be undefined references.
This is my first time trying to make a simple library. I worked in Ubuntu 12.04 with g++ 4.6.3. Here is the problem:
[[mylib.cpp]]
#include<sqlite3.h>
void Mylib::blahblah() {...}
void Mylib::evenmoreblah() {...}
...
[[mylib.h]]
#include <...>
class Mylib {
...
};
Then I made the lib by:
gcc -c -Wall -fpic mylib.cpp
gcc -shared -o libmylib.so mylib.o
I used the library in a single test.cpp which contains only the main(). I put libmylib.so in ./libdir, and compiled by using:
g++ -g test.cpp -o test -lpthread -L/usr/local/lib -lsqlite3 -L./libdir -lmylib
The error I got:
./libdir/libmylib.so: undefined reference to `sqlite3_close'
./libdir/libmylib.so: undefined reference to `sqlite3_exec'
./libdir/libmylib.so: undefined reference to `sqlite3_free'
./libdir/libmylib.so: undefined reference to `sqlite3_open'
You could link -lsqlite3 into your shared library with
gcc -shared mylib.o -o libmylib.so -lsqlite3
If you do that, you don't need to explicitly link -lsqlite3 to your program, but that won't harm.
and the order of linking arguments for your program is important:
g++ -Wall -g test.cpp -o mytest \
-L./libdir -lmylib -L/usr/local/lib -lsqlite3 -lpthread
it should go from higher-level libraries to lower-level (i.e. system) ones. And don't forget -Wall to get almost all warnings from the compiler, which is very useful.
Read the Program Library HowTo.
PS. Don't call your program test which is a shell builtin (and the standard /usr/bin/test). Use some other name.
If your library make references to sqlite3, you should link sqlite after linking your library :
g++ -g test.cpp -o test -lpthread -L/usr/local/lib -L./libdir -lmylib -lsqlite3
Otherwise ld won't find anything useful in libsqlite3 before linking your library and won't be able to find the requested symbols after that.
Since your library uses sqlite3, you need to add that AFTER your own library in the linker command. I think you could add it to the linking of your shared library too, but not certain.
The linker resolves libraries and their references in the order you list them, so the order is important.