What difference: -lX11 option vs. target_link_libraries in CMake - makefile

I need to use OpenGL as a library in my project on my Ubuntu 15.04 64bit PC, which is built by CMake 3.0.2. I install packages: mesa-common-dev mesa-utils-extra libgl1-mesa-dev libglu1-mesa-dev libglapi-mesa libx11-dev libxi-dev libxinerama-dev libxcursor-dev libxrandr-dev
After run cmake and Makefile, I got these link error:
/usr/bin/ld: /home/user/CMU462/DrawSVG/asst1_drawsvg/lib/libglfw.a(x11_window.c.o): undefined reference to symbol 'XConvertSelection'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.so: error adding symbols: DSO missing from command line
I checked /usr/lib/x86_64-linux-gnu/libX11.so, it does exist.
I found a explanation, it seems I failed to link my project with X11 library. The answer says that add -lX11 option may fix this.
Alternatively I link
X11 library in CMakeLists.txt according to FindX11.cmake:
find_package(X11 REQUIRED)
message(STATUS "X11_FOUND = ${X11_FOUND}")
message(STATUS "X11_INCLUDE_DIR = ${X11_INCLUDE_DIR}")
message(STATUS "X11_LIBRARIES = ${X11_LIBRARIES}")
include_directories(${X11_INCLUDE_DIR})
link_directories(${X11_LIBRARIES})
target_link_libraries(MyProj ... ${X11_LIBRARIES})
Run cmake I got these output:
-- X11_FOUND = 1
-- X11_INCLUDE_DIR = /usr/include
-- X11_LIBRARIES = /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
But I still got the error aforementioned.
QUESTION: The X11 library can be linked by
using target_link_libraries in CMakeLists.txt, or
adding -lX11 option directly to compiling command
What's the difference between them? Does the link in CMakeLists.txt directly lead to a -lX11 option in Makefile generated?
If so, did I do something wrong in CMakeLists.txt?
UPDATE
Let's take this project as example, following is my build procedure.
Install required libraries: Install the OpenGL and other relative libraries (the GLEW and GLFW library is provided in this project): mesa-common-dev mesa-utils-extra libgl1-mesa-dev libglu1-mesa-dev libglapi-mesa libxi-dev libxinerama-dev libxcursor-dev libxrandr-dev
Run CMake: Then use the provided CMakeLists.txt, everything goes right.
Make: When make the project, this error occurred:
/usr/bin/ld: /home/user/CMU462/DrawSVG/asst1_drawsvg/lib/libglfw.a(x11_window.c.o): undefined reference to symbol 'XConvertSelection'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.so: error adding symbols: DSO missing from command line
I have searched for many times, all of the answers say that the incorrect link of glfw3 and x11 lead to the error:
missing the -X11 option. However in line 26 of CMakeLists.txt exists this option
the libraries show arranged in order. I check the dependencies with pkg-config --libs command, all libraries are arranged in order in line 17 to 29 of CMakeLists.txt.
The only potential reason for this is the order of the compile options of libraries (line 17 to 29) and the target_link_libraries (line 116) of CMakeLists.txt.
Otherwise, there must be another error omitted by me during my procedure.

Related

Linking ports libraries under FreeBSD

I have built some libraries (gtk3, qt5, ...) through the ports collection under FreeBSD 11.2. In order to test them I just built minimal examples. Each time the linker complains about not finding these libraries.
Correct me if I am wrong, but under FreeBSD, regular packages (those which are setup with pkg) are installed under /usr/include and /usr/lib, however ports lie, by default, under /usr/local/include and /usr/local/lib.
Is there a simple way to tell the compiler to search under these directories rather than having huge compilation commands with the -I and -L options?
Thank you for your answers.
Edit
Here is my CMakeLists.txt:
cmake_minimum_required(VERSION 3.12)
project(gtk-test)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/modules/")
find_package(GTK3 REQUIRED)
include_directories(${GTK3_INCLUDE_DIRS})
link_directories(${GTK3_LIBRARY_DIRS})
add_executable(gtk-test gtk-test.c)
target_link_libraries(gtk-test ${GTK3_LIBRARIES})
I have solved the dependencies issue by grabbing the following CMake script:
https://github.com/eiskaltdcpp/eiskaltdcpp/blob/master/cmake/FindGTK3.cmake
However, another problem has pop up:
[100%] Linking C executable gtk-test
/usr/lib/crt1.o: In function `_start':
crt1.c:(.text+0x91): undefined reference to `main'
collect2: error: ld returned 1 exit status
Edit
I am stupid, I even did not notice that there was no main function in the sample. It works fine except that, by default, CMake cannot locate GTK3 library and its dependencies.
Here is the content of my CMake config scripts:
Qt5
Qt53DQuick
Qt53DRender
Qt5DataVisualization
Qt5Location
Qt5OpenGLExtensions
Qt5QuickTest
Qt5SerialBus
Qt5UiPlugin
Qt5WebKit
Qt5XmlPatterns
Qt53DAnimation
Qt53DQuickAnimation
Qt5Bluetooth
Qt5Designer
Qt5Multimedia
Qt5Positioning
Qt5QuickWidgets
Qt5SerialPort
Qt5UiTools
Qt5WebKitWidgets
assimp-4.1
Qt53DCore
Qt53DQuickExtras
Qt5Charts
Qt5Gamepad
Qt5MultimediaWidgets
Qt5PrintSupport
Qt5Script
Qt5Sql
Qt5WebChannel
Qt5WebSockets
harfbuzz
Qt53DExtras
Qt53DQuickInput
Qt5Concurrent
Qt5Gui
Qt5Network
Qt5Qml
Qt5ScriptTools
Qt5Svg
Qt5WebEngine
Qt5Widgets
libxml2
Qt53DInput
Qt53DQuickRender
Qt5Core
Qt5Help
Qt5Nfc
Qt5Quick
Qt5Scxml
Qt5Test
Qt5WebEngineCore
Qt5X11Extras
Qt53DLogic
Qt53DQuickScene2D
Qt5DBus
Qt5LinguistTools
Qt5OpenGL
Qt5QuickControls2
Qt5Sensors
Qt5TextToSpeech
Qt5WebEngineWidgets
Qt5Xml

clang linking error: DSO missing

I tried to compile a project from my lab, the only things I changed from the original code using ccmake are:
CMAKE_CXX_COMPILER /usr/bin/clang++
CMAKE_CXX_FLAGS -fPIC -std=c++11
CMAKE_EXE_LINKER_FLAGS -stdlib=libc++
The project also depends from another lib that I compiled using the same options. The compiling works well but the linking fails at some points and give us
/usr/bin/ld: main.cpp.o: undefined reference to symbol '_ZNSsC1EOSs##GLIBCXX_3.4.14'
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
The code is compiling on another machine but for some reasons, we do not manage to compile on this system. We tried a lot of things without success.
main.cpp.o: undefined reference to symbol '_ZNSsC1EOSs##GLIBCXX_3.4.14'
The -stdlib=libc++ should be used both at link and at compile time. I suspect that adding it to CMAKE_CXX_FLAGS will solve the problem.

GCC not using Boost folder include flag

I have a project that includes a library that uses boost 1.57, which is also included. However, the GCC compiler (default Xcode CLI tools v6.0 GCC version 4.2.1) does NOT pick up boosts include directory while it DOES pick up other directories. What is going on here?
This is the final GCC command being issued:
gcc -g -stdlib=libstdc++ -Wall -Wno-error -ferror-limit=1000 -fmessage-length=0
-DHCUBE_NOGUI -DTIXML_USE_STL -DMACOS -mmacosx-version-min=10.5 -arch i386 -arch x86_64
-I/Applications/Webots6.3.0/include/controller/c
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/tinyxmldll/include
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/NE/HyperNEAT/NEAT/include
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/JGTL/include
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/boost_1_57_0/boost/ -DXML1
-c ModHyperNEAT/mod_ctrler7.cpp -o controllers/mod_ctrler7_1.o
The error GCC gives me:
In file included from ModHyperNEAT/mod_ctrler7.cpp:30:
In file included from /Users/mtw800/experimentSuite/experiment/../HyperNEAT/NE/HyperNEAT/NEAT/include/NEAT.h:4:
In file included from /Users/mtw800/experimentSuite/experiment/../HyperNEAT/NE/HyperNEAT/NEAT/include/NEAT_Globals.h:4:
/Users/mtw800/experimentSuite/experiment/../HyperNEAT/NE/HyperNEAT/NEAT/include/NEAT_Defines.h:23:10:
fatal error: 'boost/shared_ptr.hpp' file not found
#include <boost/shared_ptr.hpp>
^
1 error generated.
make: *** [experiment-modular] Error 1
The boost include path:
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/boost_1_57_0/boost/
exists and invoking a find `pwd` -name shared_ptr.hpp gives the following result:
MW-020708:boost_1_57_0 mtw800$ pwd
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0
MW-020708:boost_1_57_0 mtw800$ find `pwd` -name shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/asio/detail/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/interprocess/smart_ptr/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/serialization/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/smart_ptr/shared_ptr.hpp
/Users/mtw800/experimentSuite/HyperNEAT/boost_1_57_0/boost/thread/csbl/memory/shared_ptr.hpp
So I know that the boost include library is there, the path is correct and even the header file for shared_ptr is there. Why is GCC not picking up my include folder path?
I have tested that the other include paths ARE being picked up (as they should) by removing all -I flags and re-adding them when GCC gave errors that it could not find them.
The curious thing is, that if i install boost with home-brew, and further change nothing, that my compile script just 'works', because homebrew probably links boost into directories that are searched by GCC by default. That's great, however, I don't want GCC to use the homebrew boost because it has to compile on a system that does NOT use homebrew. What do I do? Why is GCC pestering me by only excluding one include folder and not all the others? what kind of non-deterministic compiler automagick is going on here?
I am using OSX Yosemite 10.10, mentioned Xcode developer tools above. The other computer uses the same OSX and the same GCC (same Xcode dev tools).
You need to remove the last element (boost) from:
-I/Users/mtw800/experimentSuite/experiment/../HyperNEAT/boost_1_57_0/boost/
Given source files use #include <boost/whatever.h>, the preprocessor expects to find the boost sub-directory when it searches that include directory.

cmake cannot find glib2

On OS X 10.8.2, I have macports and have installed:
glib2
pkg-config
among other things. The cmake I run tries to use pkg-config to find glib2. Running pkg-config --libs glib-2.0:
-L/opt/local/lib -lglib-2.0 -lintl
and --cflags:
-I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include
Yet, when I try to enter these in (individually, or all of them using ; or :), and all sorts of combinations, or when I tried downloading gtk and using the glib2 dirs of that: cmake complains it can't find the directories:
checking for module 'gstreamer-0.10'
found gstreamer-0.10, version 0.10.36
checking for module 'glib-2.0'
found glib-2.0, version 2.34.3
CMake Error at /Applications/CMake 2.8-10.app/Contents/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
Could NOT find GLib2 (missing: GLIB2_LIBDIR GLIB2_INCLUDE_DIRS)
Call Stack (most recent call first):
/Applications/CMake 2.8-10.app/Contents/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/FindGLib2.cmake:127 (find_package_handle_standard_args)
cmake/Modules/FindGStreamer.cmake:12 (find_package)
CMakeLists.txt:32 (find_package)
I saw this page about conflicting pkg-config's with MonoDevelop. I uninstalled Mono, don't have any other pkg-config binaries that I can find, and cleared the cmake cache without any luck. I've looked at the cmake specifics, and its looking for glib.h and glibconfig.h, which are in those directories. Why can't it just behave?
Try to use this file: http://svn.opensync.org/branches/3rd-party-cmake-modules/modules/FindGLIB2.cmake
In your main CMakeLists.txt file, enter the following line:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/helper/")
This is assuming that the above FindGLIB2.cmake is stored in directory /helper off the src.
The contents of this file will help CMake to better find GLIB2.
This link will help you understand how these files work: http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#Writing_find_modules
I faced this problem while building wireshark-3.4.2 from source using cmake on Centos8.2/RHEL8.2. The error was
Could NOT find GLIB2 (missing: GLIB2_LIBRARY GLIB2_MAIN_INCLUDE_DIR GLIB2_INTERNAL_INCLUDE_DIR) Required is at least version "2.32.0")
while my system had preinstalled glib-2.56.4
Solution: Installed glib2-devel package. Then cmake found the glib-2.0 properly.
The cmake output looked like:
-- Checking for one of the modules 'glib-2.0'
-- Found GLIB2: /usr/lib64/libglib-2.0.so (found suitable version "2.56.4", minimum required is "2.32.0")

Problem with linking against libexpat in Boost Build - for building graphml

On my system, expat is located at
/usr/include/expat.h
/usr/include/expat_external.h
/usr/lib/libexpat.1.5.0.dylib
/usr/lib/libexpat.1.dylib
/usr/lib/libexpat.dylib
/usr/lib/libexpat.la
So I export the required variables for boost to build graphml
export EXPAT_INCLUDE=/usr/include
export EXPAT_LIBPATH=/usr/lib
then I run (where $DIR and $BOOST generate the paths I want the includes and libs to go)
./configure --includedir=$DIR/$BOOST --libdir=$DIR/$BOOST/lib \
--with-libraries=test,graph
I get this error:
ld: library not found for -lexpat collect2: ld returned 1 exit status
which boost says is caused by the line:
g++ -dynamiclib -install_name "libboost_graph-mt-1_35.dylib" -L"/usr/lib"
-o "bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/libboost_graph-mt-1_35.dylib"
"bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/read_graphviz_spirit.o"
"bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/graphml.o"
-lexpat -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wl,-dead_strip -no_dead_strip_inits_and_terms
I don't get how it's not finding the expat library with -L"/usr/lib" and -lexpat as arguments? My understanding is that /usr/lib/libexpat.dylib is exactly referenced as -L"/usr/lib" and -lexpat.
The Jamfile for building graphml is here. If EXPAT_INCLUDE and EXPAT_LIBPATH aren't set then it warns you (lines 39-41 of jamfile)
warning: Graph library does not contain optional GraphML reader.
note: to enable GraphML support, set EXPAT_INCLUDE and
note: directories containing the Expat headers and libraries, respectively.
Another update:
I don't see an .so or a .a file in your list of where EXPAT is... doesn't that seem a bit strange? Normally it will create an alias for the library name
for example /usr/lib/libblah.so -> /usr/lib/libblaah.so.1.2
Is dynalib some Macintoshism (I don't use Macs much)
is .la the static version extension on this platform?
Update:
The quotes around the path seem troublesome...
-L"/usr/lib"
Try changing this to -L/usr/lib and -L /usr/lib
Older stuff:
The directive for the linker to include paths during the link step is -L. You need to look for some linker flags to update to include -L path_to_expat. I don't think the linker pays any attention to LD_LIBRARY_PATH. I am not sure what documentation you have read to set EXPAT_INCLUDE or EXPAT_LIBPATH.

Resources