From the perspective of an application development platform, Qt runs on top of QNX Neutrino RTOS . System integrators and application developers use a QNX SDP (Software Development Platform) which includes QNX Neutrino RTOS components for various targets and a full set of development tools. QNX Software Systems also provides additional packages which enrich the standard feature set of QNX Neutrino RTOS. Currently, those packages are:
Qt 5 is currently tested and supported on QNX SDP 6.6 with QNX SDK for Apps and Media, see the section 构建要求 for more details. Supported architectures are ARMle-v7 and x86. Older QNX SDP releases and other architectures may also work, but are not subject to regular builds and testing.
For a specific list of available boards, displays and input devices, contact QNX Software Systems (info@qnx.com) or KDAB (qnx-info@kdab.com). Qt on the QNX Neutrino OS is also supported by Qt Enterprise Embedded, contact The Qt Company 了解更多细节。
Almost all Qt Essential 模块 and some add-ons are supported on the QNX Neutrino RTOS. See the status page on the Qt Project wiki 了解细节。
If you build Qt from a released source code distribution archive, the
configure
tool ensures that the build will be made only for modules which are known to build for the target specified. Additionally, you can explicitly exclude unsupported or not needed modules from the build via the
-skip <module>
option when running the
configure
工具。
If you build Qt directly from the Git repository, you should initialize the repository only with modules which are supported or build and install modules separately. This helps to prevent unexpected build problems.
Building Qt 5 requires the following packages available from the QNX website (an access requires registration):
fontconfig
and multimedia support along with other features. In this case, Qt will use the internal font database instead of
fontconfig
，和
multimeida
will be not functional.
The compiler and other parts of the tool chain are provided in the SDP packages. You do not need any additional installations on your host PC. Still, it is advisable to ensure that you can build Qt on the host for the desktop target as well. See 构建 Qt 源 for more details. All supported QNX Neutrino RTOS targets are fully integrated in the makespecs provided in the Qt sources. You just need to specify the target name for cross-compilation when configuring a Qt build:
For ARM:
./configure -xplatform qnx-armle-v7-qcc
For x86:
./configure -xplatform qnx-x86-qcc
The
configure
tool runs various tests to detect capabilities of the SDP and its add-ons. It sets related flags according the test results. Check the configure summary on the console or in
./qtbase/config.summary
if needed and set other flags manually as required. See
Qt 配置选项
了解更多细节。
Independent of the platform you are building for, consider using the
-prefix
option with
configure
as well, for example,
-prefix <Qt-install-path>
. This specifies the target folder where Qt will be installed and places all build artifacts outside of the source code tree.
QNX Software Systems delivers software solutions for making embedded devices. This includes creation of QNX Neutrino RTOS boot images in a very flexible way. Even though QNX provides several reference scripts for the OS image creation, sooner or later you will need to make changes or you might decide to create an OS image from scratch. Qt relies on the existence of several third-party components and selected OS services. Due to this, QNX Neutrino RTOS boot images for a target device running Qt must meet a couple of requirements to ensure that Qt works as expected. The sections below list the crucial parts for Qt.
Before any Qt application can be started, the
QNX 屏幕图形子系统
(also called just "Screen") must be running. The Screen consists not only of a driver, but also includes several utilities and other services which are used by Qt. This includes processing of mouse and keyboard events as well. You can ensure that the Screen is configured and running correctly by verifying that a graphics application, like
gles2-gears
, can be started and runs without problems. Most of the recent sample OS build scripts in the SDP include sections with all components and start commands for the Screen. Use them as a reference.
Qt's networking stack
requires IPv6 support to be enabled, independent of whether the actual networking uses IPv4 or IPv6. That means, that
io-pkt-v6-hc
must be running,
not
io-pkt-v4
.
/dev/random
Qt requires
/dev/random
to be present and functional. Start it before starting any Qt application or during the system startup:
random -p waitfor /dev/random
QNX provides the
slog2
logging framework tailored to specifics of embedded systems. The major advantage of it is a much better performance than a text output to files. Qt uses this framework by default for any logging output going through
QDebug
on QNX Neutrino RTOS. The
slog2
service should be started during the system startup. The
slog2
also relies on the existence of the
/tmp
folder which has to be configured as well, for example:
[type=link] /tmp=/dev/shmem display_msg "Starting slogger2..." slogger2 -U1001:1000 & waitfor /dev/slog2
There is a set of environment variables you should set when starting a Qt application. Most of them are actually not specific to QNX Neutrino RTOS. They are still mentioned here, since knowing them just saves a lot of time in case of problems.
If you did not build Qt with RPATH enabled, you can place the Qt runtime components in any folder in the file system. The following environment variables should point to valid locations assuming that the Qt installation is located in
<Qt-install-path>
:
LD_LIBRARY_PATH
should contain the path to the Qt libraries in
<Qt-install-path>/lib
QT_PLUGIN_PATH
defines where the Qt plug-ins are located. It should be set to
<Qt-install-path>/plugins
QML2_IMPORT_PATH
defines where the Qt Quick 2 plug-ins are located. It should be set to
<Qt-install-path>/qml
QML_IMPORT_PATH
is required only when using the Qt Quick 1 compatibility module. It should be set to
<Qt-install-path>/imports
QT_QPA_FONTDIR
to
<Qt-install-path>/lib/fonts
Qt needs information about the physical dimensions of the attached display to determine DPI values and thus set correct font sizes. Usually, this information is provided by the Screen. In some cases you may see an invalid screen size such as 0mmx0mm. In such a case Qt requires an environment variable
QQNX_PHYSICAL_SCREEN_SIZE
set to according values to get the required information. If Qt applications exit with an error message saying that the physical screen size couldn't be determined, set the variable like this before starting the Qt application:
export QQNX_PHYSICAL_SCREEN_SIZE=150,100
to inform Qt that the screen has a width of 150mm and a height of 100mm in this particular case. The physical screen size is measured in millimeters (mm) and should correspond the actual physical size of the display in the final configuration.
The only drawback of the large flexibility provided by QNX Neutrino RTOS is a risk that something is still different on your target than it is expect to be by Qt. This is a very common reason why the first Qt application on a new target fails to start. A few generic environment variables can help finding the root cause for problems:
QT_DEBUG_PLUGINS
to
1
helps to see why the QPA plug-in cannot load.
LD_DEBUG
to
1
helps to see where and how shared libraries are loaded. This can be used in combination with
QT_DEBUG_PLUGINS
when a plug-in cannot be loaded because it cannot load some other shared libraries.
QT_LOGGING_TO_CONSOLE
will force sending all logging message to
stderr
而不是
slog2
. This is very handy to analyze application startup problems, since you do not need to use another tool to see the messages.
Make sure that your system image contains the following additional 3rd-party libraries which are not always included in minimal QNX Neutrino RTOS images:
libfontconfig
(provided in addition to a standard SDP 6.6 installation)
libfreetype
libiconv
libicui18n
libicudata
libicuuc
libpng14
libxml2
libsqlite3
libssl
libcrypto
Please note that the above list is not a full list of shared libraries used by Qt on QNX Neutrino OS. Quite some shared libraries are already available in typical OS images or included by other parts of the system, e.g. by the Screen.
setconf
and
getconf
are required to access POSIX environment variables, especially for the host name and time and date.
A QNX Neutrino RTOS target used for development with Qt Creator should provide a few additional command line tools and services.
Deployment and remote application startup relies on SSH. The SSH daemon (
sshd
) must be installed and running during the system startup. Please note that it requires
/dev/random
which was already mentioned. It also expects specific access rights to be set correctly to its configuration files. The latter makes it impossible starting SSH from a file system which does not have full access rights support, for example, FAT.
scp
and
sftp
utilities are used by Qt Creator for deployment and should be available on the target. Additionally,
inetd
daemon has to be started at the system startup which then launches according services, including FTP when needed.
Remote debugging requires the
pdebug
(
process-level debugger
) to be running on the development device. It is usually started by the
qconn
process which also provides various process information to Qt Creator. Generally, Qt Creator uses the same remote debugging interfaces as the QNX Momentics IDE provided in the SDP. See the according
文档编制
了解更多细节。
Most of the OS build scripts include a set of standard command line utilities. A few more utilities are expected by Qt Creator and should be provided on a target:
printf
awk
ps
tar
zip
unzip
sed
Run the test when you configure a new target device in Qt Creator to verify that all required components are available and running.
Qt Creator deploys an application to the target device before starting it remotely. On most embedded devices, it is just copying application binaries and related data files to a folder on the target device. The challenge herewith is that there is no standard so far how this folder is called and where it is located. Quite a few configurations use
/tmp
for this, which is often mapped to a RAM disk. This case causes a lot of confusion since deployed applications disappear on the next device shutdown. Another popular target is
/opt
. This folder is located in a read-only partition on many systems making deployment impossible. Make sure that you use a destination folder which meets your needs. You can set it in the
install.path
变量在
.pro
file of your project, see
安装文件
在
QMake
文档编制了解更多细节。