SOLUTION: I just added -lpthread -ldl flags to my makefile and it works! Have no idea why, but I'm lucky enough to avoid compiling of sqlite3 by hand as I was trying.. Hmm, anyway some answers where pretty good. Thanks guys, will go and drink some tea for you.
Three months ago I was able to find how to do that but now it is not working. I have a huge C++ app, where I need to embed the sqlite3 code, but I can't compile it. I use something like this:
gcc sqlite3.c -lpthread -ldl -o ./sqlite3.o
But it does not work; I have tried a lot of variations. I have a makefile, where I added sqlite3.h and sqlite3.c files. When I do make && make install in my app's particular folder, it shows errors:
.libs/sqlite3.o: In function `pthreadMutexTry':
/home/.../client/sqlite3.c:17769: undefined reference to `pthread_mutex_trylock'
.libs/sqlite3.o: In function `pthreadMutexAlloc':
/home/.../client/sqlite3.c:17637: undefined reference to `pthread_mutexattr_init'
/home/.../client/sqlite3.c:17638: undefined reference to `pthread_mutexattr_settype'
/home/.../client/sqlite3.c:17640: undefined reference to `pthread_mutexattr_destroy'
This means that I need to add the -lpthread flag, when trying to compile sqlite3 separately from the app. Well, I am stuck.
The order of the libraries on the command line when linking matters. Put the libraries (-lpthread -ldl) last.
You need -c flag to produce an object file and not link. And skip the libraries — you pass them when linking the entire application.
gcc -c -o sqlite3.o sqlite3.c
Related
I'm trying to compile a program on Ubuntu 11.10 that uses the Boost libraries. I have the 1.46-dev Boost libraries from the Ubuntu Repository installed, but I get an error when compiling the program.
undefined reference to boost::system::system_category()
What is it that I do wrong?
The boost library you are using depends on the boost_system library. (Not all of them do.)
Assuming you use gcc, try adding -lboost_system to your compiler command line in order to link against that library.
Linking with a library that defines the missing symbol (-lboost_system) is the obvious solution, but in the particular case of Boost.System, a misfeature in the original design makes it use boost::system::generic_category() and boost::system::system_category() needlessly. Compiling with the flag -DBOOST_SYSTEM_NO_DEPRECATED disables that code and lets a number of programs compile without requiring -lboost_system (that link is of course still needed if you explicitly use some of the library's features).
Starting from Boost 1.66 and this commit, this behavior is now the default, so hopefully fewer and fewer users should need this answer.
As noticed by #AndrewMarshall, an alternative is to define BOOST_ERROR_CODE_HEADER_ONLY which enables a header-only version of the code. This was discouraged by Boost as it can break some functionality. However, since 1.69, header-only seems to have become the default, supposedly making this question obsolete.
Another workaround for those who don't need the entire shebang: use the switch
-DBOOST_ERROR_CODE_HEADER_ONLY.
If you use CMake, it's add_definitions(-DBOOST_ERROR_CODE_HEADER_ONLY).
The above error is a linker error... the linker a program that takes one or more objects generated by a compiler and combines them into a single executable program.
You must add -lboost_system to you linker flags which indicates to the linker that it must look for symbols like boost::system::system_category() in the library libboost_system.so.
If you have main.cpp, either:
g++ main.cpp -o main -lboost_system
OR
g++ -c -o main.o main.cpp
g++ main.o -lboost_system
When using CMAKE and find_package, make sure it is :
find_package(Boost COMPONENTS system ...)
and not
find_package(boost COMPONENTS system ...)
Some people may have lost hours for that ...
I got the same Problem:
g++ -mconsole -Wl,--export-all-symbols -LC:/Programme/CPP-Entwicklung/MinGW-4.5.2/lib -LD:/bfs_ENTW_deb/lib -static-libgcc -static-libstdc++ -LC:/Programme/CPP-Entwicklung/boost_1_47_0/stage/lib \
D:/bfs_ENTW_deb/obj/test/main_filesystem.obj \
-o D:/bfs_ENTW_deb/bin/filesystem.exe -lboost_system-mgw45-mt-1_47 -lboost_filesystem-mgw45-mt-1_47
D:/bfs_ENTW_deb/obj/test/main_filesystem.obj:main_filesystem.cpp:(.text+0x54):
undefined reference to `boost::system::generic_category()
Solution was to use the debug-version of the system-lib:
g++ -mconsole -Wl,--export-all-symbols -LC:/Programme/CPP-Entwicklung/MinGW-4.5.2/lib -LD:/bfs_ENTW_deb/lib -static-libgcc -static-libstdc++ -LC:/Programme/CPP-Entwicklung/boost_1_47_0/stage/lib \
D:/bfs_ENTW_deb/obj/test/main_filesystem.obj \
-o D:/bfs_ENTW_deb/bin/filesystem.exe -lboost_system-mgw45-mt-d-1_47 -lboost_filesystem-mgw45-mt-1_47
But why?
When I had this, problem, the cause was the ordering of the libraries. To fix it, I put libboost_system last:
g++ mingw/timer1.o -o mingw/timer1.exe -L/usr/local/boost_1_61_0/stage/lib \
-lboost_timer-mgw53-mt-1_61 \
-lboost_chrono-mgw53-mt-1_61 \
-lboost_system-mgw53-mt-1_61
This was on mingw with gcc 5.3 and boost 1.61.0 with a simple timer example.
in my case, adding -lboost_system was not enough, it still could not find it in my custom build environment. I had to use the advice at Get rid of "gcc - /usr/bin/ld: warning lib not found" and change my ./configure command to:
./configure CXXFLAGS="-I$HOME/include" LDFLAGS="-L$HOME/lib -Wl,-rpath-link,$HOME/lib" --with-boost-libdir=$HOME/lib --prefix=$HOME
for more details see Boost 1.51 : "error: could not link against boost_thread !"
...and in case you wanted to link your main statically, in your Jamfile add the following to requirements:
<link>static
<library>/boost/system//boost_system
and perhaps also:
<linkflags>-static-libgcc
<linkflags>-static-libstdc++
I tried to run .c file called grover.c in this C application libquantum
www.libquantum.de/files/libquantum-1.1.1.tar.gz
Now I this application already contains a Makefile.in and I can generate the executables called shor and grover using the command
./configure
make
make demos
But when I try to run grover.c using gcc or clan like this
clang grover.c
It gives me error of lots of undefined function reference.
In function oracle':
grover.c:(.text+0x50): undefined reference toquantum_sigma_x'
grover.c:(.text+0x89): undefined reference to quantum_toffoli'
grover.c:(.text+0xc8): undefined reference toquantum_toffoli'
grover.c:(.text+0xf2): undefined reference to quantum_cnot'
grover.c:(.text+0x137): undefined reference toquantum_toffoli'
grover.c:(.text+0x16b): undefined reference to quantum_toffoli'
grover.c:(.text+0x1b0): undefined reference toquantum_sigma_x'
I need to know how can I remove this error and if I can run this c code called grover.c in this application.
Thanks,
It looks like your compiler can not find one or more libraries to link to. My hunch is that the makefile has the appropriate commands to invoke the linker.
If you look at your makefile, you probably will see some commands like -L -l,
when the flag -L add a directory to the default search path for libraries and the flag -l is used to name the library to link.
for example -L/lib/openGL -lglut32 would cause the library libglut32.so.X.Y.Z which is found in the directory /lib/openGL. (not this is for a Linux system, but it should be fairly similar for Mac).
N.B. X.Y.Z are the version number of the library.
Once you work this out, there may be issues with the load finding the libraries, especially if they are in non-standard locations.
------------------------ edit --------------------------
After I posted this, and went to bed I realized that I missed a potential case (and thanks to Paul Griffiths for also noticing my omission.....teach me to do multiple things at once).
Any how, just compiling a simple file, say hello.c, as clang hello.c -o hello works because everything is in one file and clang will automatically link to the C run-time library.
If, in your case the code is spread across multiple files, say grover.c and file1.c you would need to do:
clang -c grover.c -o grover.o
clang -c file1.c -o file1.o
clang grover.o file1.o -o grover
(or alteratively clang grover.c file1.c -o grover)
SO what the first two lines are doing is translating the source-code files (grover.c and file1.c) into object files. THe third line covers the two object files into an executable.
Finally, both these cases can be involved. You could have multiple files as well as missing libraries.
I'm trying to compile a program on Ubuntu 11.10 that uses the Boost libraries. I have the 1.46-dev Boost libraries from the Ubuntu Repository installed, but I get an error when compiling the program.
undefined reference to boost::system::system_category()
What is it that I do wrong?
The boost library you are using depends on the boost_system library. (Not all of them do.)
Assuming you use gcc, try adding -lboost_system to your compiler command line in order to link against that library.
Linking with a library that defines the missing symbol (-lboost_system) is the obvious solution, but in the particular case of Boost.System, a misfeature in the original design makes it use boost::system::generic_category() and boost::system::system_category() needlessly. Compiling with the flag -DBOOST_SYSTEM_NO_DEPRECATED disables that code and lets a number of programs compile without requiring -lboost_system (that link is of course still needed if you explicitly use some of the library's features).
Starting from Boost 1.66 and this commit, this behavior is now the default, so hopefully fewer and fewer users should need this answer.
As noticed by #AndrewMarshall, an alternative is to define BOOST_ERROR_CODE_HEADER_ONLY which enables a header-only version of the code. This was discouraged by Boost as it can break some functionality. However, since 1.69, header-only seems to have become the default, supposedly making this question obsolete.
Another workaround for those who don't need the entire shebang: use the switch
-DBOOST_ERROR_CODE_HEADER_ONLY.
If you use CMake, it's add_definitions(-DBOOST_ERROR_CODE_HEADER_ONLY).
The above error is a linker error... the linker a program that takes one or more objects generated by a compiler and combines them into a single executable program.
You must add -lboost_system to you linker flags which indicates to the linker that it must look for symbols like boost::system::system_category() in the library libboost_system.so.
If you have main.cpp, either:
g++ main.cpp -o main -lboost_system
OR
g++ -c -o main.o main.cpp
g++ main.o -lboost_system
When using CMAKE and find_package, make sure it is :
find_package(Boost COMPONENTS system ...)
and not
find_package(boost COMPONENTS system ...)
Some people may have lost hours for that ...
I got the same Problem:
g++ -mconsole -Wl,--export-all-symbols -LC:/Programme/CPP-Entwicklung/MinGW-4.5.2/lib -LD:/bfs_ENTW_deb/lib -static-libgcc -static-libstdc++ -LC:/Programme/CPP-Entwicklung/boost_1_47_0/stage/lib \
D:/bfs_ENTW_deb/obj/test/main_filesystem.obj \
-o D:/bfs_ENTW_deb/bin/filesystem.exe -lboost_system-mgw45-mt-1_47 -lboost_filesystem-mgw45-mt-1_47
D:/bfs_ENTW_deb/obj/test/main_filesystem.obj:main_filesystem.cpp:(.text+0x54):
undefined reference to `boost::system::generic_category()
Solution was to use the debug-version of the system-lib:
g++ -mconsole -Wl,--export-all-symbols -LC:/Programme/CPP-Entwicklung/MinGW-4.5.2/lib -LD:/bfs_ENTW_deb/lib -static-libgcc -static-libstdc++ -LC:/Programme/CPP-Entwicklung/boost_1_47_0/stage/lib \
D:/bfs_ENTW_deb/obj/test/main_filesystem.obj \
-o D:/bfs_ENTW_deb/bin/filesystem.exe -lboost_system-mgw45-mt-d-1_47 -lboost_filesystem-mgw45-mt-1_47
But why?
When I had this, problem, the cause was the ordering of the libraries. To fix it, I put libboost_system last:
g++ mingw/timer1.o -o mingw/timer1.exe -L/usr/local/boost_1_61_0/stage/lib \
-lboost_timer-mgw53-mt-1_61 \
-lboost_chrono-mgw53-mt-1_61 \
-lboost_system-mgw53-mt-1_61
This was on mingw with gcc 5.3 and boost 1.61.0 with a simple timer example.
in my case, adding -lboost_system was not enough, it still could not find it in my custom build environment. I had to use the advice at Get rid of "gcc - /usr/bin/ld: warning lib not found" and change my ./configure command to:
./configure CXXFLAGS="-I$HOME/include" LDFLAGS="-L$HOME/lib -Wl,-rpath-link,$HOME/lib" --with-boost-libdir=$HOME/lib --prefix=$HOME
for more details see Boost 1.51 : "error: could not link against boost_thread !"
...and in case you wanted to link your main statically, in your Jamfile add the following to requirements:
<link>static
<library>/boost/system//boost_system
and perhaps also:
<linkflags>-static-libgcc
<linkflags>-static-libstdc++
I'm trying to build some code. Here is the error I'm getting:
main.o: In function `__static_initialization_and_destruction_0':
/home/jmbeck/Downloads/boost_1_48_0/boost/system/error_code.hpp:214: undefined reference to `boost::system::generic_category()'
There is more, but I don't think it's relevant.
Here is the build command:
g++ -I/home/jmbeck/Downloads/boost_1_48_0
-L/home/jmbeck/Downloads/boost_1_48_0/stage/lib
-lm
-lboost_system
-lboost_thread
-lboost_regex
main.cpp
The /home/jmbeck/Downloads/boost_1_48_0/stage/lib directory contains the expected files:
libboost_system.a
libboost_system.so#
libboost_system.so.1.48.0*
libboost_thread.a
libboost_thread.so#
libboost_thread.so.1.48.0*
libboost_regex.a
libboost_regex.so#
libboost_regex.so.1.48.0*
... etc...
I've tried building a quick program that didn't use the pre-compiled libraries, and it compiled just fine. It finds the appropriate headers, but not the libraries.
What am I doing wrong?
Try putting the libraries after main.cpp.
I've experienced some weirdness in the past when GCC ignores libraries because it doesn't think they're used, before reaching my source files.
Often linkers require that libraries be ordered as most dependent to least dependent (I believe MS does not). In this case probably thread or regex depends on system, so you'd need to list the -lsystem after the other boost library that depends on it.
I have this assignment due that requires the usage of FLTK. The code is given to us and it should compile straight off of the bat, but I am having linking errors and do not know which other libraries I need to include.
I currently have "opengl32", "fltk_gl", "glu32", and "fltk" included (-l), each of which seem to reduce the number of errors. I compiled FLTK using make with no specified options. Including all of the produced library files doesn't fix the problem, and I'm convinced that it's just some Windows specific problem.
Compile log:
**** Build of configuration Debug for project CG5 ****
make all
Building target: CG5.exe
Invoking: Cygwin C++ Linker
g++ -o"CG5.exe" ./src/draw_routines.o ./src/gl_window.o ./src/my_shapes.o ./src/shape.o ./src/shapes_ui.o ./src/tesselation.o -lopengl32 -lfltk_z -lfltk_gl -lglu32 -lfltk
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x197): undefined reference to `_SelectPalette#12'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x1a7): undefined reference to `_RealizePalette#4'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x1fe): undefined reference to `_glDrawBuffer#4'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x20d): undefined reference to `_glReadBuffer#4'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x23a): undefined reference to `_glGetIntegerv#8'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x2c3): undefined reference to `_glOrtho#48'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfltk_gl.a(Fl_Gl_Window.o):Fl_Gl_Window.cxx:(.text+0x2f3): undefined reference to `_SwapBuffers#4'
...and lots more
Thanks a ton for the help.
EDIT: These first few lines are obviously OpenGL related, although I'm still not sure what additional libraries need to be included.
Just a guess: your makefile was written for Linux, and on Cygwin some libraries are either missing or in a different place. You're going to have to examine the makefile, locate the missing libraries, and either move the libs to where the makefile expects them or change the makefile to look in the right place.
The libraries it needs are listed on the line starting g++ (prepend 'lib' to the names after the -l flags)
Sorry for the lack of closure, but I just booted into my Linux netbook and got it working.
-lfltk -lfltk_gl -lGLU -lGL -lXext -lX11 -lm