Qt w/ Cmake: set(QT_USE_QTWEBKIT TRUE) not working - c++

I'm attempting to build a Qt-based application using cmake (It's what Kdevelop gave me). I tried to use a QWebView;
QWebView *webView = new QWebView( this );
webView->load(QUrl("http://google.ca"));
But it failed with Undefined Reference errors...
undefined reference to `QWebView::QWebView(QWidget*)'
undefined reference to `QWebView::load(QUrl const&)'
I looked it up and I needed to add QTWEBKIT to my project, but all the solutions said to add it to my .pro file... And I'm not using .pro. In the QT documentation it said to add "set(QT_USE_QTWEBKIT TRUE)" to my CMAKE file, this is my CMakeLists.txt file now:
#-------------------------------------------------------------------------------
# Corrections Tool CMAKE list
#-------------------------------------------------------------------------------
project(corrections)
# Versioning Requirements
#-------------------------------------------------------------------------------
cmake_minimum_required(VERSION 2.6)
find_package(Qt4 REQUIRED)
# Include QT Librtaries
#-------------------------------------------------------------------------------
set(QT_USE_QTWEBKIT TRUE)
# Set Sources
#-------------------------------------------------------------------------------
set(corrections_SRCS corrections.cpp main.cpp utilities.cpp prettySplash.cpp)
#The Rest
#-------------------------------------------------------------------------------
include_directories(${QT_INCLUDES} ${CMAKE_CURRENT_BINARY_DIR})
qt4_automoc(${corrections_SRCS})
add_executable(corrections ${corrections_SRCS})
target_link_libraries(corrections ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY})
install(TARGETS corrections RUNTIME DESTINATION bin)
But I'm still getting the errors, so either I did it wrong, in the wrong place, etc. I've also cleaned out and reconfigured my project several times making sure I wasn't using a bad generated makefile.
How would I either fix my cmake config to actually work, or convert my project to using .pro (with minimum stress & heartache)?
Thank you.

The canonical way to select Qt components in CMake is to specify the them in the find_package call and then to include ${QT_USE_FILE}
FIND_PACKAGE( Qt4 COMPONENTS QtWebKit REQUIRED )
INCLUDE( ${QT_USE_FILE} )
...
TARGET_LINK_LIBRARIES( corrections ${QT_LIBRARIES} )
This already configures the include directories and sets ${QT_LIBRARIES} to contain all relevant Qt libraries (i.e. your selected component and all Qt libraries it depends on).
So you don't need to manually add the libraries by listing them individually as you did in your example.
Edit:
Additional explaination:
The COMPONENTparameter to FIND_PACKAGE actually does the same as your manual call to set QT_USE_WEBKIT. But this variable is only evaluated/used in UseQt4.cmake which is included (and "executed") by the INCLUDEcommand. See CMake documentation of FindQt4 for details.

You do not appear to be linking against all of the Qt libraries. Use ${QT_LIBRARIES} instead of ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY} in your target_link_libraries
target_link_libraries(corrections ${QT_LIBRARIES} )

Related

CMake BUILD undefined reference (findpng)

I'm still very new to CMake so feedback is definitely welcome. So, I'm trying to build a simple application that should eventually create a pdf using the library libharu.
I think i figured it out how to link the library. But I still receive build errors for the findpng module (I suppose libharu depends on it)
CMakeLists.txt:
cmake_minimum_required(VERSION 3.2.0 FATAL_ERROR) # current latest stable version (if lower give FATAL_ERROR)
project(pdf_generator VERSION 0.1.0) # name of the project, version.
file(GLOB TARGET_SRC "./src/*.cpp") # Creates variable, using globbing.
include_directories(${PROJECT_SOURCE_DIR}/include) # list of directories to be used as header search paths.
add_executable(main ${TARGET_SRC}) # Create an executable of set of source files [exe name files to bundle].
find_library(libhpdf_location NAMES libhpdf.a) # find the location of libhpdf.a and save the value in the variable libhpdf_location.
message(STATUS ${libhpdf_location}) # print status of variable.
add_library(libhpdf STATIC IMPORTED) # Add library via a static import.
set_target_properties(
libhpdf PROPERTIES
IMPORTED_LOCATION ${libhpdf_location}
)
target_link_libraries(main libhpdf)
I've never worked with that particular library before, but skimming their CMakeLists.txt on GitHub it seems like libharu has optional dependencies on libpdf and zlib. Without knowing how you built your version of libharu I'm going to assume that both are needed.
Luckily, CMake comes with find-modules for both libpng and zlib, so adding the following should work:
find_package(PNG REQUIRED)
find_package(ZLIB REQUIRED)
set_target_properties(libhpdf
PROPERTIES
INTERFACE_LINK_LIBRARIES "ZLIB::ZLIB;PNG::PNG"
)
Looks like all you need to do is tell cmake to link libpng.

Using SDL2 with CMake in CLion

After hours of scouring the web and SO for a solution I'm at a standstill. Nothing has worked so far for me...
I'm on Windows, using CLion IDE which uses CMake. My goal is to correctly link SDL2 to my project and use it through #include "SDL.h" which is the correct way.
The format of my CMakeLists.txt file
Specifics regarding the directory where I should have put the MingW development library of SDL2
Any requirements regarding windows ENV variables that I might have to set.
My CMakeLists.txt looks like this:
cmake_minimum_required(VERSION 3.6)
project(sdl2Project)
set(CMAKE_CXX_STANDARD 11)
#This is where sdl2-config.cmake is located
set(CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} "C:/Users/MyUserName/CLibraries/SDL2-2.0.5/x86_64-w64-mingw32/lib/cmake/SDL2")
set(SOURCE_FILES main.cpp)
add_executable(sdl2Project ${SOURCE_FILES})
find_package(sdl2 REQUIRED)
target_include_directories(sdl2Project PUBLIC ${SDL2_INCLUDE_DIRS})
target_link_libraries(sdl2Project ${SDL2_LIBRARIES})
There is no FindSDL2.cmake file used.
The SDL2 library I downloaded from libsdl.org is located in:
C:/Users/MyUserName/CLibraries/SDL2-2.0.5/x86_64-w64-mingw32
I have no experience with CMake so I'm unable to truly understand where the problem stems from. What are the steps I need to take in order for it to find the library and link it correctly??
EDIT:
My Project structure is the following:
sdl2Project
cmake-build-debug
CMakeLists.txt
main.cpp
Looking in your FindSDL2.cmake, you need to provide an hint to CMake about where the library is installed. You could do this by setting an environment variable SDLDIR, but you shouldn't. General advice: you shouldn't use a CMake package that wasn't provided with the sources you're using.
Looking in sources of SDL2, root directory contains a file sdl2-config.cmake.in that should have been configured and installed in your install directory as sdl2-config.cmake: that's the package file you should use.
Am I right guessing the file C:/Users/MyUserName/CLibraries/SDL2-2.0.5/sdl2-config.cmake exists?
If yes, to allow CMake to find it, add your install directory to CMAKE_PREFIX_PATH, before calling find_package:
set(CMAKE_PREFIX_PATH
${CMAKE_PREFIX_PATH}
"C:/Users/MyUserName/CLibraries/SDL2-2.0.5"
)
find_package(sdl2 REQUIRED)
Note the use of "/" in the path instead of "\" which could be interpreted as escaping character. Quotes around the path are only necessary if the path contains whitespaces.
EDIT:
Moreover, you misused target_link_libraries with a wrong target: SDL2 which you don't build in your project, instead of sdl2Project.
You also used a wrong variable: SDL2_LIBRARY instead of SDL2_LIBRARIES; you can see the good variable name by looking in sdl2-config.cmake.
You may consider target_include_directories instead of include_directories, but again the variable name you used is wrong: SDL2_INCLUDE_DIR instead of SDL2_INCLUDE_DIRS.
Try:
target_include_directories(sdl2Project PUBLIC ${SDL2_INCLUDE_DIRS})
target_link_libraries(sdl2Project ${SDL2_LIBRARIES})

Cmake cannot find library using "link_directories"

I Ubuntu, I am learning about cmake and make, and just trying a simple example. I have two directories: src and build. In src, I have two files: main.cpp, and CMakeLists.txt, which has (only) the following text:
add_executable(test main.cpp)
link_directories(/usr/lib/x86_64-linux-gnu)
target_link_libraries(test protobuf)
In /usr/lib/x86_64-linux-gnu, there is a shared library called libprotobuf.so, which I want to link against. My main.cpp uses functions in this library, by including the releveant header file, #include <google/protobuf/message.h>.
Now, in my build directory, I run cmake ../src, and then make. However, I then get linker errors telling me that there are undefined references to some of the functions in the protobuf library. If I do a search through all the files and subdirectories in build, there is not mention of anything related to protobuf.
However, if I remove the link_directories line in my CMakeLists.txt file, and instead write the full path to the library when specifying the executable, i.e. target_link_libraries(test /usr/lib/x86_64-linux-gnu/libprotobuf.so), it compiles and links fine.
Why is link_directories not allowing cmake to find this library?
Do not use link_directories like this in CMake.
This is a common beginner's mistake, as many other build environments work like this, but in CMake it's just asking for trouble. Even the official documentation specifically advises against it:
Note that this command [link_directories] is rarely necessary. Library locations returned
by find_package() and find_library() are absolute paths. Pass these
absolute library file paths directly to the target_link_libraries()
command. CMake will ensure the linker finds them.
So instead, always pass absolute paths to target_link_libraries and use find_library to resolve the link directory:
find_library(PROTOBUF_LIBRARY protobuf HINTS /usr/lib/x86_64-linux-gnu)
target_link_libraries(test PUBLIC ${PROTOBUF_LIBRARY})
This has the huge benefit that you will probably get a diagnostic at CMake configure time if the expected library cannot be found, instead of a random linker error at compile time. Also, this allows the user to specify a library location via the GUI if the target machine has a non-standard directory layout.
So if it doesn't work right away, be sure to check the result of the find_library call and consult the official documentation to track down why it doesn't find your library as intended.
Make sure that your call to link_directories takes place before your call to the relevant add_executable.
I had mistakenly believed it only needed to be before the call to target_link_libraries, but that's not the case. After moving the call, the library is linked properly.
Make sure that the order will be link_directories, set PROJECT_LINK_LIBS, add_executable and then target_link_libraries.
Below is example to demonstarte it:
cmake_minimum_required(VERSION 2.8.9)
project (Logging)
include_directories(include)
file(GLOB LOGGINGSOURCES "libsrc/*.cpp")
file(GLOB SOURCES "src/*.cpp")
add_library(convertString SHARED ${LOGGINGSOURCES})
install(TARGETS convertString DESTINATION /root/Deepak/)
link_directories( /root/Deepak/ )
set(PROJECT_LINK_LIBS libconvertString.so)
add_executable(hello ${SOURCES})
target_link_libraries(hello ${PROJECT_LINK_LIBS} )
Perhaps it's very old topic but none of proposed solutions worked for me. So I had to make my own dirty hack. I do crosscompiling with buildroot and include toolchainfile.cmake.
#...
set(LIB_PATH ${PROJECT_SOURCE_DIR}/relative/path/to/your/lib)
#...
include_directories(/path/to/library/include)
set(LIB_MYLIB ${LIB_PATH}/libmylib.so)
#...
add_executable(${PROJECT_NAME} ${APP_SOURCES})
target_link_libraries(${PROJECT_NAME}
${LIB_MYLIB}
)
Hope this will help

Qt Creator cannot find library with custom cmake step

In Qt Creator (version 3.0.1, with Qt version 5.2.1), I have made a custom cmake step (instead of qmake), with the following CMakeLists.txt file:
cmake_minimum_required (VERSION 2.8)
add_executable (myapp source.cpp)
target_link_libraries(myapp dl)
In my source.cpp file, I have the following code:
#include <dlfcn.h>
int main()
{
dlopen("mylibrary.so", RTLD_NOW|RTLD_GLOBAL);
return 0;
}
And mylibrary.so is located in /usr/lib.
When I compile this using cmake and make from the command line, it compiles as expected. However, if I try to build this in Qt Creator, I receive the following error:
undefined reference to `dlopen'
This suggests that Qt Creator does not know where to look to find libdl.so, which is in /usr/lib/x86_64-linux-gnu.
So my question is: Why does running cmake and make from the command line work, whereas building in Qt Creator does not work? And how do I tell Qt Creator where to search for libdl.so?
First of all, you should use QLibrary in Qt software for dealing with dynamic loading, lookup and the like. You would also spare the hassle that you are seeing now.
Secondly, you can use this, but it is a bit hard-wiring things, admittedly:
target_link_libraries(myapp /usr/lib/x86_64-linux-gnu/libdl.so)
Thirdly, the even better approach would be to use some find module for this as follows:
# - Find libdl
# Find the native LIBDL includes and library
#
# LIBDL_INCLUDE_DIR - where to find dlfcn.h, etc.
# LIBDL_LIBRARIES - List of libraries when using libdl.
# LIBDL_FOUND - True if libdl found.
IF (LIBDL_INCLUDE_DIR)
# Already in cache, be silent
SET(LIBDL_FIND_QUIETLY TRUE)
ENDIF (LIBDL_INCLUDE_DIR)
FIND_PATH(LIBDL_INCLUDE_DIR dlfcn.h)
SET(LIBDL_NAMES dl libdl ltdl libltdl)
FIND_LIBRARY(LIBDL_LIBRARY NAMES ${LIBDL_NAMES} )
# handle the QUIETLY and REQUIRED arguments and set LIBDL_FOUND to TRUE if
# all listed variables are TRUE
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(LibDL DEFAULT_MSG LIBDL_LIBRARY LIBDL_INCLUDE_DIR)
IF(LIBDL_FOUND)
SET( LIBDL_LIBRARIES ${LIBDL_LIBRARY} )
ELSE(LIBDL_FOUND)
SET( LIBDL_LIBRARIES )
ENDIF(LIBDL_FOUND)
MARK_AS_ADVANCED( LIBDL_LIBRARY LIBDL_INCLUDE_DIR )
and then you can find it as follows given that you have it in your cmake module path:
find_package(LIBDL REQUIRED)

Compiling error: "cannot find -lQtCore4"

Yesterday I downloaded the Qt4 Opensource library for linux. After running
./configure
./make
./make install
And inserting this into my .bashrc-file:
PATH=/usr/local/TrollTech/Qt-4.7.3/bin:$PATH
export PATH
After this, I ran cmake in order to produce a Makefile for me. CMakeLists.txt:
project(VTKToVTFx)
cmake_minimum_required(VERSION 2.6)
find_package(VTK REQUIRED)
find_package(Qt4 REQUIRED)
include(${VTK_USE_FILE})
include(${QT_USE_FILE})
SET(VTK_TO_VTFX_FORMS main.ui)
QT4_WRAP_UI(VTK_TO_VTFX_FORMS_UIC ${VTK_TO_VTFX_FORMS})
SET(MOC_HEADERS VTKToVTFx.h)
qt4_wrap_cpp(MOC_OUTFILES ${MOC_HEADERS})
SET(CPP_SOURCES VTKToVTFx.cpp
VTKPatch.cpp
VTKFile.cpp
VTKData.cpp
VTKDataHolder.cpp
)
add_executable(VTKToVTFx ${CPP_SOURCES} ${VTK_TO_VTFX_FORMS_UIC} ${MOC_OUTFILES})
# Adds folders for Visual Studio solution explorer (and for Xcode explorer)
source_group( "Generated" FILES ${MOC_FILES_CPP} ${VTK_TO_VTFX_FORMS_UIC} ${QRC_FILES_CPP} ${MOC_OUTFILES})
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
target_link_libraries(VTKToVTFx vtkHybrid)
target_link_libraries(VTKToVTFx QtCore4)
target_link_libraries(VTKToVTFx QtGUI4)
This CMakeLists.txt works perfectly well on Windows, but when I try to compile the output on my installation of Ubuntu, this error occurs:
/usr/bin/ld: cannot find -lQtCore4
/usr/bin/ld: cannot find -lQtGUI4
Anyone who could point me to my problem here?
In the unix[like] world, the slash is the path seperator, not the backslash.
\usr\local\TrollTech\Qt-4.7.3\bin evaluates to usrlocalTrollTechQt-4.7.3bin.
edit: Also, your CMakeLists.txt seems a bit foul. Have a look at http://qtnode.net/wiki/Qt4_with_cmake . Instead of
target_link_libraries(VTKToVTFx QtCore4)
use something like (source is the linked site):
To add support for Qt4 libraries like network or qttest, you need to add both the include files and corresponding libraries. For example, to add support for the network and qttest libraries, you can use:
INCLUDE_DIRECTORIES(
${QT_INCLUDE_DIR}
${QT_QTNETWORK_INCLUDE_DIR}
${QT_QTTEST_INCLUDE_DIR}
)
TARGET_LINK_LIBRARIES(
${QT_LIBRARIES}
${QT_QTNETWORK_LIBRARIES}
${QT_QTTEST_LIBRARIES}
)
Even within the 4.x line of releases, libraries have been renamed and will be renamed. Fortunately there is no need for hardcodery :)