I have been trying to build cairo as a static library with support for cairo's experimental Qt features (I cannot use the official GTK binary releases). My Qt installation has no pkg-config within Mingw so I decided it would be easiest to cross-compile cairo on linux.
Using this cross compiler http://mingw-cross-env.nongnu.org/ and the commands:
./configure --prefix=/tmp/cairo --host=i686-pc-mingw32 --enable-qt
make
make install
I received an error generated by -Werror about implicit declaration of a function, however after modifying the makefile cairo builds correctly.
I copy the contents of /tmp/cairo to my MinGW installation under windows however when I try to compile a simple test program I receive the error when linking:
undefined reference to `cairo_qt_surface_create'
on the code:
QPainter p(viewport());
cairo_surface_t *surface = cairo_qt_surface_create(&p);
cairo_t *cr = cairo_create(surface);
I am using qmake for this test and included the following as extra library's:
-lcairo -lcairo-gobject -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0
Related
I want to develop a small program that checks which polygons from a shapefile intersect a given rectangle. This program is to be used in a website (with PHP's exec() command). The problem is, my webserver cannot install GDAL, for reasons unknown to me. So I can't link to the shared libraries. Instead, I must link to static libraries, but these aren't given.
I've downloaded the GDAL source code from here (2.3.2 Latest Stable Release - September 2018), and followed the build instructions from here. Since I already have GDAL working on my Debian, and don't want to mess with it, I followed the "Install in non-root directory" instructions, with some adjusts from the last item in the "Some caveats" section:
cd /home/rodrigo/Downloads/gdal232/gdal-2.3.2
mkdir build
./configure --prefix=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/ --without-ld-shared --disable-shared --enable-static
make
make install
export PATH=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/bin:$PATH
export LD_LIBRARY_PATH=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib:$LD_LIBRARY_PATH
export GDAL_DATA=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/share/gdal
/usr/bin/gdalinfo --version
build/bin/gdalinfo --version
The first /usr/bin/gdalinfo --version gives 2.1.2 (the previous installed version). The second, build/bin/gdalinfo --version, gives 2.3.2 (the version just built).
By now, my program only uses the ogrsf_frmts.h header, which is in /usr/include/gdal/ or /home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/include/ directory, depending on the build. There's no ogrsf_frmts.a file, but only a libgdal.a. Is this the file I should be linking against? If so, how? I've tried so far:
gcc geofragc.cpp -l:libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l:libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l:/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp /home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -l/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -l:/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
but nothing works. What am I missing?
EDIT
The second trial (gcc geofragc.cpp -Wl,-Bstatic -l:libgdal.a) is giving the following error:
/usr/bin/ld: cannot find -lgcc_s
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libgdal.a(gdalclientserver.o): In function `GDALServerSpawnAsync()':
(.text+0x1f5e): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
You can use the gdal-config program to get correct options for compilation and linking. This program is a part of the GDAL library and it has its own options:
hekto#ubuntu:~$ gdal-config --help
Usage: gdal-config [OPTIONS]
Options:
[--prefix[=DIR]]
[--libs]
[--dep-libs]
[--cflags]
[--datadir]
[--version]
[--ogr-enabled]
[--gnm-enabled]
[--formats]
You have to make sure this program is on your search path, or you can create an alias - for example:
alias gdal-config='/home/rodrigo/Downloads/gdal232/gdal-2.3.2/bin/gdal-config'
Now your compilation and linking command becomes the following one:
g++ `gdal-config --cflags` geofragc.cpp `gdal-config --libs` `gdal-config --dep-libs`
You have to use the g++ compiler to link with C++-built libraries.
Another option is to create a Makefile with these lines:
CXXFLAGS += ${shell gdal-config --cflags}
LDLIBS += ${shell gdal-config --libs}
LDLIBS += ${shell gdal-config --dep-libs}
geofragc: geofragc.cpp
and just call make with this Makefile.
I hope, it'll help.
I am using Qt 5.6 with Qt Creator 4.3 on macOS Sierra 10.12.
I am building a Qt based application that uses OpenGL and OpenCL.
Software or system updates somewhere appear to have broken Qt Creators' ability to find the headers for OpenGL and OpenCL headers.
I have tried reinstalling Qt, Reinstalling Xcode and the Mac SDK and none of these options make it work.
The weird thing is my app compiles. QtCreator just cannot find the headers itself - this makes code navigation somewhat more complex.
So lets take OpenCL. I include it like this:
#ifdef __APPLE__
#include <OpenCL/cl.h>
#include <OpenCL/opencl.h>
#endif
My app.pro file for qmake has the following inside it:
macx:QMAKE_LFLAGS += -framework OpenCL
And with this it seems to compile. However the two OpenCL #include above in QtCreator are yellow underlined with a tooltip saying "OpenCL/cl.h: No such file or directory".
Now I can see that it compiles successfully as qmake is working out where the frameworks are and appending the paths successfully:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -stdlib=libc++ -g -std=gnu++11 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.7 -Wall -W -fPIC -DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/Users/me/Projects/app -I. -I/Users/me/Qt5.6.2/5.6/clang_64/lib/QtWidgets.framework/Headers -I/Users/me/Qt5.6.2/5.6/clang_64/lib/QtGui.framework/Headers -I/Users/me/Qt5.6.2/5.6/clang_64/lib/QtCore.framework/Headers -I. -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/AGL.framework/Headers -I. -I/Users/me/Qt5.6.2/5.6/clang_64/mkspecs/macx-clang -F/Users/me/Qt5.6.2/5.6/clang_64/lib -o main.o /Users/me/Projects/app/main.cpp
Now if I navigate to the following directory the headers are there and present:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenCL.framework/Versions/A
So I cannot see what is missing.
I have tried to "teach" Qt Creator about this framework directory with combinations of the following, but I havent found something that will work:
macx:QMAKE_LFLAGS += -framework OpenCL
macx:INCLUDEPATH += /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenCL.framework/Versions/A/Headers
macx:QMAKE_LFLAGS += -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
macx:LIBS += -framework OpenCL
I'm struggling to find information about how QtCreator find the system frameworks on a mac and how i get it to start finding them again. Any help would be massively appreciated.
For anybody that has the same problem the answer was actually rather simple in the end.
When you setup the kit in Qt creator (which tells it what compiler and debugger to use amongst other things) you need to be careful with the compiler used. I had two copies of clang on my machine, one was installed in /usr/bin (the system one) and the other was installed inside the XCode app bundle. My kit was using the Xcode installed one as thats where the libraries live. While this compiled just fine, Qt creator for some reason does not hook up the paths to libraries properly. Simply switching this over to using the one in /usr/bin solved it.
Note that i did not explicitly ask it to use the one in the Xcode app bundle, thats just the one that was automatically selected when the project was first opened in Qt creator. So you might have to adjust its default behaviour in order to fix things.
I have compiled qt 5.5 for static building and it works fine.
However, when I add the widgets "QT += widgets" in the pro file I get the link error "cannot find -IGL"
From what I read this is to do with the Open GL libs. I have tried the following:
sudo apt-get install libglu1-mesa-dev
and
sudo apt-get install libgl1-mesa-dev
But no luck here... I am wondering if I need a static version of this? or maybe a symlink is missing, but I can't figure out the next step :(
Edit This is the actual error message:
g++ -static -static-libgcc -static-libstdc++ -Wl,-O1 -o ../targetRel/McpSupervisor main.o cconfig.o cconfigxml.o mcpprocessbase.o rpeprocess.o supervisor.o cipcomms.o mcpsupervisor_plugin_import.o moc_mcpprocessbase.o moc_supervisor.o moc_cipcomms.o -L/usr/lib/i386-linux-gnu/mesa -L/usr/local/Qt-5.5.1/lib -lQt5Xml -lQt5Widgets -L/usr/local/Qt-5.5.1/plugins/bearer -lqconnmanbearer -lqgenericbearer -lqnmbearer -lQt5Network -L/usr/local/Qt-5.5.1/plugins/platforms -lqxcb -L/usr/local/Qt-5.5.1/plugins/xcbglintegrations -lqxcb-glx-integration -lxcb-glx -lQt5XcbQpa -lX11-xcb -lXi -lxcb-render-util -lxcb-render -lxcb -lxcb-image -lxcb-icccm -lxcb-sync -lxcb-xfixes -lxcb-shm -lxcb-randr -lxcb-shape -lxcb-keysyms -lxcb-xkb -lQt5PlatformSupport -lfontconfig -lfreetype -lQt5DBus -lXrender -lXext -lX11 -L/usr/local/Qt-5.5.1/plugins/imageformats -lqdds -lqicns -lqico -lqjp2 -lqmng -lqtga -lqtiff -lqwbmp -lqwebp -lQt5Gui -lpng -lqtharfbuzzng -lQt5Core -lz -licui18n -licuuc -licudata -lqtpcre -lm -ldl -pthread -lgthread-2.0 -lglib-2.0 -lrt -lGL -lpthread
/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libX11.a(CrGlCur.o): In function open_library':
(.text+0x33): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -lGL
/usr/local/Qt-5.5.1/plugins/imageformats/libqjp2.a(jas_stream.o): In functionjas_stream_tmpfile':
jas_stream.c:(.text+0x7a4): warning: the use of tmpnam' is dangerous, better usemkstemp'
/usr/local/Qt-5.5.1/lib/libQt5Core.a(qfilesystemengine_unix.o): In function QFileSystemEngine::resolveGroupName(unsigned int)':
qfilesystemengine_unix.cpp:(.text+0x943): warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In functiong_get_user_database_entry':
(.text+0x25a): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function g_get_user_database_entry':
(.text+0xa3): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/local/Qt-5.5.1/lib/libQt5Core.a(qfilesystemengine_unix.o): In functionQFileSystemEngine::resolveUserName(unsigned int)':
qfilesystemengine_unix.cpp:(.text+0x592): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/local/Qt-5.5.1/lib/libQt5Network.a(qhostinfo_unix.o): In function `QHostInfoAgent::fromName(QString const&)':
qhostinfo_unix.cpp:(.text+0x580): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
collect2: error: ld returned 1 exit status
make: *** [../targetRel/McpSupervisor] Error 1
09:49:17: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project qtMain (kit: Qt 5.5.1 GCC 32bit Static)
When executing step "Make"
09:49:17: Elapsed time: 00:08.
What is your actual problem :
You have unmet dependencies .
You are thinking that you have all the required dependencies because you installed
sudo apt-get install libglu1-mesa-dev
sudo apt-get install libgl1-mesa-dev
The problem is that you have a i386 system that is x32 system.
But you have installed development files for x64 systems using the commands above
Here is the ANSWER :
Intsall the following things
sudo apt-get install libgl1-mesa-dev:i386
sudo apt-get install libglu1-mesa-dev:i386
Now it should work ;)
Some other helpful stuff for visitors to this particular question
The lines below were my attempt to solve the problem but they did not work because the person who asked the question has a x32 system but the comments below work for x64 systems . But never the less the meta answer below will serve well for people who have the same problem and x64 systems. And also it will help problem to understand what are the basic steps to do after a similar problem occurs
# code_fodder I wanted to ask a question by making a comment below your question but I do not have 50 reputations to do so.
So I have to use the answer submission form to do so. :(
Do you have Miscellaneous Mesa GL utilities ?
If you dont have them then install using
sudo apt-get install mesa-utils
If you want to use OpenGl ES then you have to install Miscellaneous Mesa utilies (opengles, egl) using
sudo apt-get install mesa-utils-extra
Let me know if that works .
POSTING NEW INFORMATION ON 17-DEC-2015
I will post a portion of my project.pro file here . It specifically contains the library linking methods that I used for a simple OpenGL project.
I am using GLEW with OpenGL and SDL2
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt
SOURCES += main.cpp \
mesh.cpp \
display.cpp \
shader.cpp
HEADERS += \
mesh.h \
display.h\
shader.h
unix|win32: LIBS += -lGL \
-lGLEW \
/usr/local/lib/libSDL2-2.0.so
As you can notice I am using both static and dynamically linked libraries.
You may need to add:
unix | win32: LIBS += -L/usr/lib/x86_64-linux-gnu/mesa/ to your .pro file. However the path may be different for 32 bit systems. In that folder there are is the required mesa library files. These are the files for my system.
zehel#zehel-PC:/usr/lib/x86_64-linux-gnu/mesa$ ls
ld.so.conf libGL.so libGL.so.1 libGL.so.1.2.0
Try compiling now and see if that works
If that doesn't then either you have unmet dependencies or you are using old OpenGL.
Now after running the sudo apt-get install mesa-utils you will be able to use a command called glxinfo . It will show you all required information about your graphics card.
Run glxinfo | grep "OpenGl version string"
It will show you what version of OpenGl and mesa you have
mine is like this
OpenGL version string: 3.0 Mesa 10.3.2
If they are less than 3.0 then you are not using modern OpenGL and you may want to update your graphics drivers.
But if they are 3.0 or above then you are probably okay.
I cant reproduce your problem so I think that you have missing dependencies
See this posts on the QT forum where people with same problem as you are saying that there problems were fixed after installing the dependencies
http://forum.qt.io/topic/36282/solved-qt-5-2-0-and-lgl-issue
The last answer in the qt forum is quite good please refer it.
Update me whether it works or not .
Hope That helps .
You might need to specify the path where the GL library can be found, for exmaple by using the -L option to GCC, which has the following man page description:
-Ldir
Add directory dir to the list of directories to be searched for -l.
I recently developed a small SDL2 game. The game ran fine on my computer because I have SDL, SDL_image, SDL_mixer, and SDL_ttf installed. However, everyone who downloaded the game did not have SDL2 and the extensions installed, so they could not run the application. How can I make the application usable even for people who don't have SDL2 installed?
You can pass the -rpath option to ld to specify search directories for dynamic libraries.
Using -rpath . (-Wl,-rpath . to pass it from GCC) will enable loading the libraries from the executable's directory. Just put the appropriate .so files there and they will be found.
You could statically link you libs, that way no need to have SDL installed.
A way to do it :
g++ -o program [sources.cpp] -Wl,-Bstatic -lSDL2 -lSDL2_image \
-lSDL2_mixer -lSDL2_ttf -Wl,-Bdynamic [dynamically linked libs]
Note : If you use SDL2, you must use the SDL2 builds of peripheral libs otherwise you risk all kinds of errors.
There are various ways to cross-compile to Raspberry Pi, and there are also solutions posted for cross-compiling Qt or opencv.
However, I couldn't find any solution to cross-compile a program with Qt which also uses opencv.
I tried the following, using debian on a 64-bit PC:
I compiled and set up Qt as a cross-compiler to ARM7, using this tutorial. It didn't work without issues though, here is an answer I posted which solved it for me. I can now run my Qt programs with graphical GUI on the Raspberry Pi (although only full-screen, but that's a completely different issue)
I followed the guide on the official opencv website to build opencv. It failed with No CMAKE_CXX_COMPILER could be found.
Knowing from experience (I used Qt with opencv both on Windows and Linux) that Qt and opencv work together only if both are compiled with the same compiler, I tried to use the same cross-compiler for opencv which I used successfully to compile Qt: gcc-4.7-linaro-rpi-gnueabihf
I specified the gnueabihf I previously used to compile Qt, as the compiler:
I created the directory ~/opt/opencv_build_arm7/ and in it, I tried:
sudo cmake -DCMAKE_CXX_COMPILER=/home/<user>/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++ -DCMAKE_C_COMPILER=/home/<user>/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-gcc -DCMAKE_TOOLCHAIN_FILE=/usr/dev/opencv/platforms/linux/arm-gnueabi.toolchain.cmake /usr/dev/opencv/
(Where the downloaded opencv sources were in /usr/dev/opencv/ which I recently used successfully to compile opencv for an x64 platform, using the g++ compiler which came with my Qt installation.) Note, that <user> is the username for the current session, in case other beginners might try these methods in the future.
This failed with the following error (where <user> is my username)
CMake Error at
/usr/share/cmake-3.0/Modules/CMakeTestCXXCompiler.cmake:54 (message):
The C++ compiler
"/home//opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++"
is not able to compile a simple test program.
It fails with the following output :
Change Dir: /home//temp/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTryCompileExec117178613/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec117178613.dir/build.make
CMakeFiles/cmTryCompileExec117178613.dir/build
make1: Entering directory '/home//temp/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report
/home//temp/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec117178613.dir/testCXXCompiler.cxx.o
/home//opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++
-mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi -o CMakeFiles/cmTryCompileExec117178613.dir/testCXXCompiler.cxx.o -c /home//temp/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
/home//temp/CMakeFiles/CMakeTmp/testCXXCompiler.cxx: In
function ‘int main()’:
/home//temp/CMakeFiles/CMakeTmp/testCXXCompiler.cxx:4:10:
sorry, unimplemented: Thumb-1 hard-float VFP ABI
CMakeFiles/cmTryCompileExec117178613.dir/build.make:57: recipe for
target
'CMakeFiles/cmTryCompileExec117178613.dir/testCXXCompiler.cxx.o'
failed
make1: ***
[CMakeFiles/cmTryCompileExec117178613.dir/testCXXCompiler.cxx.o] Error
1
make1: Leaving directory '/home//temp/CMakeFiles/CMakeTmp'
Makefile:118: recipe for target 'cmTryCompileExec117178613/fast'
failed
make: *** [cmTryCompileExec117178613/fast] Error 2
I specified an absolute path for the compiler, but even if I don't specify it, and just add it to my $PATH, it still has the same problem.
export PATH=$PATH:/home/<user>/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/
sudo cmake -DCMAKE_TOOLCHAIN_FILE=/usr/dev/opencv/platforms/linux/arm-gnueabi.toolchain.cmake /usr/dev/opencv/
The compiler itself is found correctly, if I type
arm-linux-gnueabihf-g++ -v
it is found successfully:
Using built-in specs. COLLECT_GCC=./arm-linux-gnueabihf-c++
COLLECT_LTO_WRAPPER=/home/vszabi/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/4.7.2/lto-wrapper
Target: arm-linux-gnueabihf Configured with:
/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/src/gcc-linaro-4.7-2012.07/configure
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/install
--with-sysroot=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc
--enable-languages=c,c++,fortran --enable-multilib --with-arch=armv6zk --with-tune=arm1176jzf-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1-2012.07-20120720 - Linaro GCC 2012.07'
--with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-mpfr=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-mpc=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-ppl=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-cloog=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-libelf=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-host-libstdcxx='-L/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static/lib
-lpwl' --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-gold --with-local-prefix=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc
--enable-c99 --enable-long-long Thread model: posix gcc version 4.7.2 20120701 (prerelease) (crosstool-NG linaro-1.13.1-2012.07-20120720 -
Linaro GCC 2012.07)
What could I try next? Opening the gui version of cmake with opencv/platforms/linux/arm-gnueabi.toolchain.cmake shows very few options (only ARM_LINUX_SYSROOT, CMAKE_BUILD_TYPE, CMAKE_CONFIGURATION_TYPES, CMAKE_INSTALL_PREFIX, GCC_COMPILER_VERSION and LIBRARY_OUTPUT_PATH_ROOT, but none of the BUILD_opencv_xyz with which I can disable individual packages), much fewer than the case when I built opencv for an x86 or x64 platform.
I'm afraid that searching for a different compiler might cause issues with Qt, because as far as I know, for opencv to work within Qt, it has to be compiled with the same compiler as what is used both to build the Qt libraries and build my program. Whenever I tried it in the past without being careful that these 3 things (Qt libs, opencv, my program) need to be compiled with the same compiler, I always experienced weird crashes either as soon as I included any opencv header, or whenever I called any function from opencv.
The tutorial at http://docs.opencv.org/doc/tutorials/introduction/crosscompilation/arm_crosscompile_with_cmake.html seems to be either wrong or out of date.
Downloading the source of opencv 3.0, the opencv/platforms/linux/arm-gnueabi.toolchain.cmake seems to be insufficiently configured for the Raspberry Pi.
Configure
Visiting the workgroup page of the creators of the arm-linux-gnueabihf toolchain, it seems that for the ARM7 in the Raspberry Pi to be supported, the following options have to be passed to the compiler: -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4
So, we have to edit the opencv/platforms/linux/arm-gnueabi.toolchain.cmake file and change
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi")
to
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4")
running cmake again, the configuration was successfully completed!
Make
During the building process, if the following error appears
CMakeFiles/opencv_core.dir/src/rand.cpp.o: relocation
R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
CMakeFiles/opencv_core.dir/src/rand.cpp.o: could not read symbols: Bad
value
just add the -fPIC flag to the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in the cmake file and run make again.
Deployement
Using Qt Creator to deploy, just set up the headers and libraries in your .pro file, for example:
INCLUDEPATH += <your build dir>/install/include/opencv2/
INCLUDEPATH += <your build dir>/install/include/
LIBS += -L "<your build dir>/install/lib/"
LIBS += -lopencv_calib3d
LIBS += -lopencv_core
#... and so on
You also have to copy the compiled libraries (found in <your build dir>/install/lib/) to the Raspberry Pi. Using a USB stick might mess up the symlinks, so I would recommend using scp to copy the files.
If you are relatively new to Linux (just as myself), don't forget that executables don't automatically look into their own folders for dynamic libraries as they did in Windows.
Therefore you should either copy the libraries to a place which is usually searched for them (like /usr/local/bin) or update your LD_LIBRARY_PATH accordingly.
For a quick and dirty test, to see if everything works, you might copy the libraries into the same folder where your executable is deployed, and run it by using
$ LD_LIBRARY_PATH=. ./your_program
Testing
Opencv should work now in your Qt program on the Raspberry Pi.
Unless my google-fu is very weak, this might be the first documented case of running a Qt GUI application on a Raspberry Pi with opencv working in it. :)
However, note that there might still be some issues with window management.
Trying to open an opencv window, for example, cv::namedWindow("image"); might fail with the following error:
OpenCV Error: Unspecified error (The function is not implemented.
Rebuild the library with Windows, GTK+ 2.x or Carbon support. If you
are on Ubuntu or Debian, install libgtk2.0-dev and pkg-config, then
re-run cmake or configure script) in cvNamedWindow, file
/usr/dev/opencv/modules/highgui/src/window.cpp, line 516 terminate
called after throwing an instance of 'cv::Exception' what():
/usr/dev/opencv/modules/highgui/src/window.cpp:516: error: (-2) The
function is not implemented. Rebuild the library with Windows, GTK+
2.x or Carbon support. If you are on Ubuntu or Debian, install libgtk2.0-dev and pkg-config, then re-run cmake or configure script in
function cvNamedWindow
I guess we should do as it says, but cvNamedWindow is not very useful in a Qt GUI application, as it's usually only required for debugging. Therefore if the image has to be shown in your application, converting it to QImage might be better anyway than opening up an independent window.
However, everything else seems to work, I managed to successfully run complicated image matching algorithms on the Raspberry Pi.
(... will update if I find a good solution for running the Qt application in a window and using cvNamedWindow)