Qt 6.7 on VxWorks 7: Architecture, EGLFS, and Build Guide

Qt 6.7 on VxWorks 7: Architecture, EGLFS, and Build Guide

Qt 6.7 was released on April 2, 2024, introducing verified support for VxWorks 7 and providing an updated foundation for deploying Qt applications on embedded real-time systems.

For VxWorks developers, the key addition is support verified on VxWorks SR 23.09 with ARM-v7. Qt Widgets applications can run with POSIX and C++17 support, while Qt Quick 2 additionally requires GPU support compatible with OpenGL ES 2.0 through the VxWorks GPUDEV framework.

This article covers the supported VxWorks configuration, Qt modules, EGLFS platform integration, cross-compilation requirements, device-specific configuration, and deployment considerations for Qt 6.7.

🧩 VxWorks Architecture and Version Support

#

Qt 6.7 has been verified against VxWorks SR 23.09 with the following architecture:

The supported configuration is particularly relevant to embedded devices that need Qt’s application and UI framework while retaining VxWorks’ real-time operating-system characteristics.

⚙️ VxWorks System Requirements

#

Qt Widgets applications

#

Qt Widgets applications require:

• POSIX support
• C++17 compiler support

Qt Widgets can operate without a GPU because widget content can be rendered through the CPU when used with the appropriate platform configuration.

Qt Quick 2 applications

#

Qt Quick 2 requires all dependencies of Qt Widgets applications plus:

• A GPU device compatible with OpenGL ES 2.0
• VxWorks GPUDEV support
• Appropriate EGL/OpenGL ES integration for the target hardware

GPU availability is therefore an important distinction when selecting Qt Widgets versus Qt Quick for a VxWorks-based product.

📦 Supported Qt Modules

#

Qt 6.7 provides support for the essential Qt modules required by typical application, networking, UI, QML, and testing workloads.

Essential modules

#

Add-on modules

#

The following Qt add-ons are also supported:

Not every project needs the complete Qt module set. For embedded deployments, excluding unnecessary modules can reduce build time, storage requirements, and the resulting runtime footprint.

The Qt configuration system supports explicit module exclusion with:

-skip <module>

For example, an application that does not use Qt Multimedia can omit that module during configuration rather than building it into the target Qt installation.

🖥️ Qt Platform Integration on VxWorks

#

Qt’s platform architecture changed substantially after Qt 5.0. Qt no longer provides its former QWS window-system implementation, and QWS is not supported in Qt 6.

For single-process embedded deployments, Qt Platform Abstraction (QPA) provides the appropriate integration layer.

EGLFS

#

Qt 6 provides the EGLFS platform plugin for VxWorks devices.

EGLFS allows Qt applications to operate directly on top of EGL and OpenGL ES without requiring a conventional windowing system such as X11 or Wayland. This makes it particularly suitable for embedded devices that boot directly into a dedicated graphical application.

EGL provides the interface between OpenGL ES and the native platform, including graphics context and surface management. However, EGL does not define every platform-specific operation required to create and manage native display resources.

Consequently, VxWorks boards and GPUs require platform-specific integration code.

This integration can be implemented through:

• EGLFS hooks compiled directly into the platform plugin
• Dynamically loaded EGL device integration plugins
• Vendor-specific EGL/OpenGL ES porting code

The availability of EGLFS depends on how Qt is configured and built for the target platform.

EGLFS rendering model

#

EGLFS is designed for devices where Qt controls the display directly rather than relying on a desktop-style window manager.

It supports:

• Qt Quick 2 applications
• Native OpenGL applications
• CPU-rendered QWidget applications

For software-rendered widgets, Qt can render widget content into an image using the CPU. EGLFS can then upload that content as a texture and composite it through the graphics pipeline.

For modern VxWorks devices equipped with a supported GPU, EGLFS is the recommended Qt 6 platform plugin.

🔧 Preparing the Qt 6 VxWorks Build Environment

#

Building Qt 6 for a VxWorks target requires a cross-compilation environment containing:

• A Qt 6 build host
• A VxWorks-compatible compiler toolchain
• A target sysroot
• VxWorks Board Support Package (BSP) components
• Device-specific EGL/OpenGL ES integration where required

For graphics-enabled targets, the vendor-provided porting layer must expose the necessary EGL and OpenGL ES 2.0 functionality.

Before configuring or compiling Qt 6, open the VxWorks Development Shell so that the required compiler, environment variables, SDK components, and VxWorks tooling are available.

Linux host

#

On a Linux build host:

cd <VxWorks installation directory>
./wrenv.sh -p vxworks

Windows host

#

On Windows, use the VxWorks environment command:

cd <VxWorks installation directory>
wrenv -p vxworks

The exact VxWorks installation path depends on the local development environment.

🛠️ Configuring Qt 6 for a VxWorks Device

#

The following configuration illustrates a Qt 6 build for a BD-SL-i.MX6 development board.

The configuration pattern is representative of other VxWorks development boards, although the target sysroot, GPU integration library, and platform-specific options may need to be adjusted for the selected BSP.

./configure \
    -cmake-generator "Ninja" \
    -icu \
    -no-feature-timezone \
    -no-feature-vulkan \
    -platform vxworks-clang \
    -qt-host-path <path-to-qt-host> \
    -sysroot /fsl_imx6__VSB \
    -qpa "eglfs" \
    -DQT_QPA_EGLFS_INTEGRATION=eglfs_viv \
    -prefix /sd0:1/qt6rtp \
    -extprefix /qt6rtp \
    -nomake tools \
    -nomake examples

Several options are especially relevant to an embedded VxWorks build:

The eglfs_viv integration shown above is specific to the Vivante graphics stack used by the example target. Other VxWorks boards may require a different vendor-specific integration.

Shared versus static Qt builds

#

Qt 6 is configured for shared libraries by default.

To build Qt as static libraries, add:

-static

Static builds can simplify deployment by reducing runtime shared-library dependencies, but they also change application linking, update, and licensing considerations. The appropriate choice depends on the target product architecture and deployment model.

🏗️ Building and Installing Qt 6

#

After configuration completes successfully, use Ninja to compile and install Qt:

ninja
ninja install

The resulting installation contains the Qt runtime and selected modules configured for the target VxWorks environment.

For embedded products, it is generally preferable to exclude unused modules, examples, and development tools during configuration rather than carrying unnecessary components into the target filesystem.

🎨 EGLFS and GPU Integration

#

EGLFS provides the bridge between Qt’s QPA architecture and the graphics stack on a VxWorks target.

The integration chain can be viewed conceptually as:

Qt Application
      |
      v
Qt GUI / Qt Quick
      |
      v
Qt Platform Abstraction (QPA)
      |
      v
EGLFS
      |
      v
EGL / OpenGL ES 2.0
      |
      v
VxWorks GPUDEV
      |
      v
Vendor GPU Driver / Hardware

The exact lower-level implementation depends on the VxWorks BSP and GPU vendor.

For a Qt Quick application, the GPU path is particularly important because Qt Quick relies on hardware-accelerated rendering capabilities provided through the OpenGL ES stack.

A board that satisfies the CPU, POSIX, and C++ requirements for Qt Widgets may therefore still require additional BSP and GPU integration work before Qt Quick can be deployed successfully.

🚀 Running Qt Applications on VxWorks

#

When Qt 6 is built using shared libraries, the target runtime must be able to locate the required Qt and VxWorks shared libraries.

The LD_LIBRARY_PATH environment variable can be configured to include the directory containing the Qt runtime libraries and other required VxWorks libraries.

For example:

export LD_LIBRARY_PATH=/qt6rtp/lib:$LD_LIBRARY_PATH

The exact runtime path depends on the installation layout selected through -prefix and -extprefix.

Shared-library deployments may require additional runtime libraries from the VxWorks system, including components associated with:

• VxWorks C runtime
• OpenGL ES
• EGL
• Vendor GPU integration

For a statically built Qt configuration, Qt’s static libraries are linked into the application and therefore do not require the Qt shared-library path in LD_LIBRARY_PATH.

However, static linking does not eliminate all runtime dependencies. The application can still depend on VxWorks-provided shared libraries, including graphics and system libraries, depending on the target configuration.

📋 Deployment Considerations

#

A production Qt 6 application on VxWorks should be treated as a target-specific cross-compilation product rather than a generic desktop Qt build.

The main dependencies to validate are:

1. VxWorks release — verify compatibility with the target SR release.
2. CPU architecture — Qt 6.7’s verified configuration targets ARM-v7.
3. Compiler/toolchain — use the VxWorks-supported Clang environment.
4. Sysroot — ensure headers, libraries, and BSP components correspond to the target.
5. QPA integration — configure EGLFS for direct embedded display operation.
6. GPU stack — verify EGL, OpenGL ES 2.0, GPUDEV, and vendor integration for Qt Quick.
7. Qt modules — remove unnecessary modules to control image size and build complexity.
8. Runtime libraries — ensure all required shared libraries are available on the target.
9. Static versus shared linking — select the deployment model based on update, footprint, and dependency requirements.

🔍 Summary

#

Qt 6.7 provides a practical Qt 6 foundation for VxWorks 7 systems, with verified support for VxWorks SR 23.09 on ARM-v7. Qt Widgets requires POSIX and C++17 support, while Qt Quick 2 additionally depends on a compatible OpenGL ES 2.0 GPU stack.

For embedded graphical systems, EGLFS is the key QPA integration layer. It allows Qt applications to use EGL and OpenGL ES without requiring a traditional windowing system, making it well suited to dedicated VxWorks devices.

A successful Qt 6 VxWorks deployment ultimately depends on more than the Qt framework itself. The target BSP, sysroot, compiler, GPU driver, EGL/OpenGL ES implementation, and EGLFS integration must all align with the selected hardware platform.