I have Debian Wheezy and I need C++11 features to build my project. I've compiled gcc(c and c++ only) from source and put the libraries under my home folder using this question. I am also using the wrapper script supplied by the guy who answered that question which is
$HOME/gcc/gcc-4.8.4/bin/g++ -Wl,-rpath,$HOME/gcc/gcc-4.8.4/lib32 "$#"
Now, I have a game engine that I use in my project for GUI and graphic operations. It compiles in 32 bit just fine. I pass -m32 switch for all of the external libraries it uses and the engine itself. Also, in order for cmake to find my wrapper, I give following options while running cmake
cmake .. -DCMAKE_CXX_COMPILER=path/to/my/32-bit-wrapper
After compilation, it gives following linking erros
undefined reference to `XOpenDisplay'
undefined reference to `glBlendFunc'
undefined reference to `alGenBuffers'
At first, I thought I may be missing the 32-bit development libraries, so I installed following packages.
libgl1-mesa-dev:i386
libopenal-dev:i386
libx11-dev:i386
but I am getting errors, regardless. So, How can I solve this problem? I can supply additional information such as cmake files etc if needed. Thank you in advance.
EDIT
Cmake file in case if error stems from it
cmake_minimum_required(VERSION 2.8.3)
project(uwmf)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -m32 -DLINUX")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32 -DLINUX")
#set(CMAKE_CXX_COMPILER "${HOME_PATH}/devel/g++-4.8.4-32")
#set(CMAKE_C_COMPILER "${HOME_PATH}/devel/gcc-4.8.4-32")
message("${CMAKE_CXX_FLAGS}")
message("${CMAKE_C_FLAGS}")
message("${CMAKE_CXX_COMPILER}")
message("${CMAKE_C_COMPILER}")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin)
set(GGE ${HOME_PATH}/devel/gorgon-3.x)
set(GRAPHICS ${HOME_PATH}/devel/graphics)
set(SOURCES
src/source.cpp
src/algorithms.h
src/cloud-gen.h
src/latex.h
src/macros.h
src/matrix.h
src/utils.h
)
include_directories(${GGE})
include_directories(${GRAPHICS})
add_executable(uwmf ${SOURCES})
target_link_libraries(uwmf ${GGE}/build/libGGE.a)
UPDATE
ereOn's answer did the trick. I also had to install libalut-dev:i386 and link (-lalut) to successfully compile. I get many warning messages like the following (probably due to introducing additional linkage of same library)
/usr/bin/ld: Warning: type of symbol `glDrawBuffers' changed from 2 to 1 in ../devel/gorgon-3.x/build/libGGE.a(OpenGL.cpp.o)
/usr/bin/ld: Warning: type of symbol `glGetAttribLocation' changed from 2 to 1 in ../devel/gorgon-3.x/build/libGGE.a(OpenGL.cpp.o)
but these are not part of this question. Thank you for your help.
It could be that the symbols that are reported missing are not used by your game engine library and were thus "optimized out" to make for a smaller binary.
Try linking your target executable explicitely with -lX11 and -lGL to see if that works.
As #ereOn said, the linker could have optimized out some symbols. Try linking with -Wl,--no-as-needed.
Related
I would like to compile gtkmm programs that use mutithreading. I used this example to test multithreading.
Unfortunately I get some linking errors when I compile:
/usr/bin/ld: src/multithreadingandprogress.p/multithreadingandprogress-window.cpp.o: undefined reference to symbol 'pthread_create##GLIBC_2.2.5'
and:
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
I guess I need some LDFLAGS or some environment variables to set in the settings?? Is there anyone who knowes exactly how to set up gnome builder for this task to compile?
Any help? Thx
I had similar issues while building the same tutorial in gtkmm-3.0. Adding the following line in the CMake file fixed the issue.
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthread")
If you are not using CMake you need to add this flag for your compiler manually.
The complete CMake for using threads in linux systems must contain following commands:
set(CMAKE_THREAD_LIBS_INIT "-lpthread")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthread")
set(CMAKE_HAVE_THREADS_LIBRARY 1)
set(CMAKE_USE_WIN32_THREADS_INIT 0)
set(CMAKE_USE_PTHREADS_INIT 1)
set(THREADS_PREFER_PTHREAD_FLAG ON)
Check this link for a more complete approach with CMake.
After reading a lot of SO questions on the matter, I just couldn't get it to work. I downloaded boost_1_60_0, then I ran the commands to build it:
sudo ./bootstrp.sh --prefix=/home/ricardo/boostlib
sudo ./b2 install -j8
I even tried running b2 like this:
sudo ./b2 install -j8 architecture=x86 address-model=64
Does not matter. The error is always the same:
main.cpp:(.text+0x7e): undefined reference to `boost::system::generic_category()'
main.cpp:(.text+0x8a): undefined reference to `boost::system::generic_category()'
main.cpp:(.text+0x96): undefined reference to `boost::system::system_category()'
Yeah, I know. Linking error, should run with -lboost_system and all. Yeah, you should put -L/home/ricardo/boostlib/lib. I know.
This is what my CMake looks like:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -L/home/ricardo/boostlib/lib -lboost_system -Wl,--verbose")
include_directories("/home/ricardo/boostlib/include")
You might be asking: What's the output of -Wl,--verbose? Well, surprisingly enough, libboost_system.so has been found:
attempt to open /home/ricardo/boostlib/lib/libboost_system.so succeeded
-lboost_system (/home/ricardo/boostlib/lib/libboost_system.so)
Okay. The library was found. I'm still trying to find some alternatives, nothing seems to work so far. So, even though I'm linking it against boost, and boost_system has been found, the program still does not compile due to... why? Can someone explain me?
Edit: How to link C++ program with Boost using CMake seems to be working. Though I still would like to know why my method does not work, and what should I do when I want to link against boost using just the g++ compiler, without CMake and Make. I've been able to link against Openblas succesfully before, so I wonder why it isn't working with Boost.
Edit2: This is the g++ command I got after running make VERBOSE=1, now I can see that the sources are being put AFTER the dependencies.
-std=c++11 -L/home/ricardo/boostlib/lib -lboost_system CMakeFiles/prophet-service.dir/main.cpp.o -o prophet-service -rdynamic
And this is my current CMake file:
cmake_minimum_required(VERSION 3.2)
project(prophet-service)
set(SOURCE_FILES
main.cpp)
include_directories("/home/ricardo/boostlib/include")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -L/home/ricardo/boostlib/lib -lboost_system")
add_executable(prophet-service ${SOURCE_FILES})
It also seems that I don't have the libbost_system.a file. At least now I know that I need the .a file instead of the .so file.
Are you linking in the right order? The thing that HAS the dependency needs to go before the thing that SATISFIES the dependency.
You need to link version of the library with extension .a because linker requires this extension (used for static libraries) and not .so which is used for shared libraries (the same of dll for Windows).
For example, if I search for libboost_system.a on my Ubuntu operating system I find the following:
frar#Home-PC:~$ locate libboost_system.a
/home/frar/Documents/SVILUPPO/boost_1_59_0/bin.v2/libs/system/build/gcc-4.8/release/link-static/threading-multi/libboost_system.a
/home/frar/Documents/SVILUPPO/boost_1_59_0/stage/lib/libboost_system.a
/usr/lib/x86_64-linux-gnu/libboost_system.a
This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 7 years ago.
Googling aroung told me it was "wrong VS libraries" but when tried to use glew-1.5.4-mingw32 and libgluew32.a instead of glew32.lib (and same done to glut) nothing changed.
main.cpp got from project on VS2012, attaching same libs, so it may not be wrong.
Some files I use to make:
CMakeLists.txt
cmake_minimum_required(VERSION 2.8.4)
project(HelloGL)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_executable(HelloGL main.cpp)
set(LIBS_DIR D:/libs)
set(GLEW_ROOT_DIR ${LIBS_DIR}/glew-1.5.4-mingw32 )
set(GLUT_ROOT_DIR ${LIBS_DIR}/glut-3.7.6-src/glut-3.7.6 )
set(GLEW_INCLUDE_DIRS ${GLEW_ROOT_DIR}/include)
set(GLUT_INCLUDE_DIRS ${GLUT_ROOT_DIR}/include)
set(GLEW_LIBRARY ${GLEW_ROOT_DIR}/lib/libglew32.a)
set(GLUT_LIBRARY ${GLUT_ROOT_DIR}/lib/glut/libglut32.a)
include_directories( ${GLEW_INCLUDE_DIRS} ${GLUT_INCLUDE_DIRS} )
target_link_libraries(HelloGL ${GLEW_LIBRARY} ${GLUT_LIBRARY} )
Part of LOG:
"D:\Tools\CLion 140.569.17\bin\cmake\bin\cmake.exe" --build C:\Users\Alexey\.clion10\system\cmake\generated\dc6fcb22\dc6fcb22\Debug --target HelloGL -- -j 8
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Alexey/.clion10/system/cmake/generated/dc6fcb22/dc6fcb22/Debug
Linking CXX executable HelloGL.exe
CMakeFiles\HelloGL.dir/objects.a(main.cpp.obj): In function `Z11LoadShadersPKcS0_':
D:/Projects/CPP/HelloGL/main.cpp:19: undefined reference to `_imp____glewCreateShader'
D:/Projects/CPP/HelloGL/main.cpp:20: undefined reference to `_imp____glewCreateShader'
D:/Projects/CPP/HelloGL/main.cpp:56: undefined reference to `_imp____glewShaderSource'
D:/Projects/CPP/HelloGL/main.cpp:57: undefined reference to `_imp____glewCompileShader'
D:/Projects/CPP/HelloGL/main.cpp:60: undefined reference to `_imp____glewGetShaderiv'
D:/Projects/CPP/HelloGL/main.cpp:61: undefined reference to `_imp____glewGetShaderiv'
D:/Projects/CPP/HelloGL/main.cpp:64: undefined reference to `_imp____glewGetShaderInfoLog'
Try adding this line to your CMakeLists.txt:
add_definitions(-DGLEW_STATIC)
It seems that you are trying to link GLEW statically but you didn't define GLEW_STATIC
Did you compile GLEW yourself?
Generally the library called glew32 is dynamic linking and glew32s is static. MinGW really does not like the dynamic (DLL) version of GLEW and you should probably avoid it. The pre-built Windows dynamic GLEW libraries that are distributed on the GLEW site will not work with MinGW because of differences between Visual C++ and gcc's function naming convention for import libraries (it is a difference of one underscore, but enough to make life really difficult).
If you #define GLEW_STATIC before including <glew.h> and link to glew32s that will eliminate any potential issues with the dynamic linking library. In practice, this works best if you add the definition to your Makefile as Nazar554 has demonstrated.
This gist is how I compile OpenGL project in linux. Hope it helps
I am trying to compile a c++ project referencing Python using CMake. I am using Cygwin and I have Python2.7 source files in Cygwin.
For example:
PyObject *l = PyList_New(0);
Online help suggested I add the -lpython2.7 linker flag. Am I not adding this correctly in CMake? Otherwise why can I still not use the Python library and how might I fix this?
The compile line:
C:\cygwin64\bin\cmake.exe --build "C:\Users\...\.clion10\system\cmake\generated\3e6845d6\3e6845d6\Release" --target projectname -- -j 4
The CMakeList.txt file:
cmake_minimum_required(VERSION 2.8.4)
project(projectname)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -lpython2.7")
set(SOURCE_FILES
src/cpp/...
src/cpp/...
src/cpp/..
src/cpp/...
src/cpp/...)
add_executable(projectname ${SOURCE_FILES})
The errors...
CMakeFiles/spot.dir/src/cpp/OBwrapper.cpp.o:OBwrapper.cpp:(.text+0xaeb4): undefined reference to `PyDict_New'
CMakeFiles/spot.dir/src/cpp/OBwrapper.cpp.o:OBwrapper.cpp:(.text+0xaeb4): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `PyDict_New'
CMakeFiles/spot.dir/src/cpp/OBwrapper.cpp.o:OBwrapper.cpp:(.text+0xaec4): undefined reference to `PyList_New'
CMakeFiles/spot.dir/src/cpp/OBwrapper.cpp.o:OBwrapper.cpp:(.text+0xaec4): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `PyList_New'
CMakeFiles/spot.dir/src/cpp/OBwrapper.cpp.o:OBwrapper.cpp:(.text+0xaf0d): undefined reference to `PyDict_New'
CMakeFiles/spot.dir/src/cpp/OBwrapper.cpp.o:OBwrapper.cpp:(.text+0xaf0d): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `PyDict_New'
CMakeFiles/spot.dir/src/cpp/OBwrapper.cpp.o:OBwrapper.cpp:(.text+0xaf25): undefined reference to `PyString_FromString'
...and so on....
You misunderstand CMake's way: before use something you ought to find it! I.e. make sure that everything you need to build your package is available and usable at build host. Otherwise that would be not good to waste a (compile) time (say 2 hours) and then get an error that some header/library/executable not found. So, at CMake run time you'd better to be sure that everything you need is here. To do so, CMake have a lot of tools.
Consider your particular case: you need to find Python libraries otherwise build is not possible. To do so, you ought to use find_package like this:
find_package(PythonLibs REQUIRED)
Take a look to documentation and provide other options (like version) if you need. You shouldn't use hardcoded paths in your CMakeLists.txt, otherwise your project wouldn't be really portable (and most probably you'll be the only who can build it w/o a lot of problems). Instead Python libs finder module will provide variables you need to use later, or failed w/ error if nothing has found.
If CMake ends w/o errors, you may use found Python libs. First of all you need to update #include paths:
include_directories(${PYTHON_INCLUDE_DIRS})
Then tell to linker that your executable projectname needs to be linked w/ Python libs:
add_executable(projectname ${SOURCE_FILES})
target_link_libraries(projectname ${PYTHON_LIBRARIES})
And again, try to avoid to modify CMAKE_CXX_FLAGS (and others) directly -- there are bunch of calls to do that globally and/or per target. Some of them are:
add_definitions to define/undefine macros
include_directories to update #include paths
add_compile_options to add other compiler options
link_directories to update linker search paths
I'm trying to compile an application pipeline and link it with my library matlabengine, which acts as a wrapper to Matlab calls. Matlab uses it's own older version of libstc++ which is mixed in Matlab's lib folder .../bin/glnxa64
matlabengine compiles ok, but pipeline fails for unresolved symbols (because pipeline uses Matlab's libstdc++ version)
Basically i have two problem and solving either one should fix this:
Remove arguments -leng -lmx -L/usr/local/MATLAB/R2013a/bin/glnxa64 from pipeline linking, which origin from subdirectory mex. When I compile matlabengine by hand and let cmake link it to pipeline, these flags do not appear and everything is fine. Why are these added to pipeline's linking when it works perfectly without them?
Since Matlab's old libstc++ is used before the the system-wide libstdc++ i get unresolved symbols. fixing the order c++ searches for these libraries should also solve this.
Any help is much appreciated...
CMakeList.txt
link_directories("/usr/local/MATLAB/R2013a}/bin/glnxa64")
include_directories(mex)
add_subdirectory(mex)
ADD_EXECUTABLE( pipeline pipeline.cpp )
TARGET_LINK_LIBRARIES( pipeline matlabengine ${OpenCV_LIBS})
mex/CMakeList.txt (this should emulate what matlab's mex compiler wrapper does)
# mex specific c++ flags
set(MATLAB_PATH "/usr/local/MATLAB/R2013a")
set(CMAKE_CXX_COMPILER "gcc-4.4")
set(CMAKE_CXX_FLAGS "-D_GNU_SOURCE -fexceptions -DMX_COMPAT_32 -O -DNDEBUG -fPIC -DMATLAB_MEX_FILE")
include_directories("${MATLAB_PATH}/extern/include")
link_directories("${MATLAB_PATH}/bin/glnxa64")
add_library(matlabengine SHARED matlabengine.cpp)
target_link_libraries(matlabengine eng mx m)
Issue 1 can be solved by telling cmake to turn off transitive linking
mex/CMakeList.txt
set_target_properties(matlabengine PROPERTIES LINK_INTERFACE_LIBRARIES "")
Then, when linking the compiler will search for the library in the library path environment variable. Because of issue 2, the system standard library folder should precede the matlab library folder like so in linux:
export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/:/usr/local/MATLAB/R2013a/bin/glnxa64/