Building Qt for Linux Embedded (OMAP3530)
-
Hello,
I am having some trouble building the Qt libraries (tried 4.7.3 and 4.8) for a Linux Embedded running on an OMAP3530-based board (http://www.technexion.com/index.php/products/arm-cpu-modules/ti-omap3530/tao-3530).
The distribution that came with the board contains pre-compiled Qt 4.7.3 libraries and what I wanted to do is build the hellogl_es2 example in order to have a starting point for future development.
I've cloned the Qt4 git repo and positioned myself on the 4.7.3 tag. This is the sequence of commands that I've run:
@qmake -spec mkspecs/qws/linux-omap3-g++/@
with the following spec file:
@qmake configuration for building with arm-none-linux-gnueabi-g++
include(../../common/g++.conf)
include(../../common/linux.conf)
include(../../common/qws.conf)modifications to g++.conf
QMAKE_CFLAGS_RELEASE = -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
QMAKE_CXXFLAGS_RELEASE = $$QMAKE_CFLAGS_RELEASEQMAKE_CC = arm-none-linux-gnueabi-gcc
QMAKE_CXX = arm-none-linux-gnueabi-g++
QMAKE_LINK = arm-none-linux-gnueabi-g++
QMAKE_LINK_SHLIB = arm-none-linux-gnueabi-g++modifications to linux.conf
QMAKE_AR = arm-none-linux-gnueabi-ar cqs
QMAKE_OBJCOPY = arm-none-linux-gnueabi-objcopy
QMAKE_STRIP = arm-none-linux-gnueabi-stripQMAKE_LIBS_EGL = -lEGL -lIMGegl -lsrv_um
QMAKE_LIBS_OPENGL_QT = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um
QMAKE_LIBS_OPENVG = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um -lOpenVG -lOpenVGUQMAKE_INCDIR_OPENGL = ${TARGET_STAGING_PATH}/usr/include
QMAKE_LIBDIR_OPENGL = ${TARGET_STAGING_PATH}/usr/libload(qt_config)
@then ran:
@./configure -prefix-install -embedded arm -xplatform qws/linux-omap3-g++ -opengl es2 -openvg@then make, which gave the following error:
@make
cd /src/tools/bootstrap/ && /usr/local/bin/qmake /src/tools/bootstrap/bootstrap.pro -spec /home/alex/workspace/edash/software/qt-4.7.3/qt4/mkspecs/qws/linux-omap3-g++ -o Makefile
Cannot find file: /src/tools/bootstrap/bootstrap.pro.
make: *** [/src/tools/bootstrap/Makefile] Error 2
@which doesn't surprise me too much, since the Makefile contained these lines:
@/src/tools/bootstrap/$(MAKEFILE):
@$(CHK_DIR_EXISTS) /src/tools/bootstrap/ || $(MKDIR) /src/tools/bootstrap/
cd /src/tools/bootstrap/ && $(QMAKE) /src/tools/bootstrap/bootstrap.pro -spec /home/alex/workspace/edash/software/qt-4.7.3/qt4/mkspecs/qws/linux-omap3-g++ -o $(MAKEFILE)
@Any idea or hint would be highly appreciated!
Thanks,
Alex -
Try
export QTDIR=/home/alex/workspace/edash/software/qt-4.7.3/qt4
before running configure?Don't run qmake before configure, BTW, that's just wrong. Clean up everything, run configure, and then make. Configure will call qmake all by itself. You only need to call qmake for your own project afterwards.
-
Thank you for your reply!
I figured out the problem. At the end of the configure process, I got a (what I thought to be) warning saying that the OpenGL (ES) test failed. I did not realize that the process was aborted. Anyhow, I fixed the problems (got some with the EGL and TSlib tests as well) and got through the configure script.
Next, I encountered some problems with the X11 headers that defined some macros whose names were also used in enums from the Qt sources. Obviously, this led to some nasty compile errors, but, by replacing the names in the X11 headers I managed to get through those as well. By the way, what could've been the reasoning behind using camel case for macros?
In the end, I managed to build the libraries and the test application successfully, but, when put on the board, the hellogl_es2 example complained about some issues with the font library. When I'll get to my computer I'll post a log for that as well.
Alex
-
The X11 headers date from 1970, the conventions were quite different back then (or even non-existent)...
This was unrelated to C++, they used defines to define constant values for C programs, and couldn't possibly anticipate that this would affect the use of the same words inside classes or namespaces... C++ was not used with X11 initially.So yes these headers constantly create trouble, but I'm surprised you got issues when compiling Qt itself (or was that in your own code?).