Build Images

Chinese README: README.zh-CN.md

These Dockerfiles are the build-image definitions used by local verification, CI, and the legacy VisualGDB debug container.

Published images

The following seven image repositories publish a usable latest tag on GHCR. The container platform is the architecture used to run the build container; the build target column describes the binaries produced by the toolchain inside it.

Compose target	Published image	Build target and intended use	Container platform	Main-branch tags	Image size
x86-legacy (x86legacy in Compose)	ghcr.io/iotsharp/pcct-build-x86-legacy	Legacy Wheezy X86 debug environment and historical ARM + X86 VisualGDB workflow	linux/386	latest, sha-<commit>	Inspect the pulled image
x86	ghcr.io/iotsharp/pcct-build-x86	Native LaneApp i386 build and verification	linux/386	latest, sha-<commit>	Inspect the pulled image
arm	ghcr.io/iotsharp/pcct-build-arm	ARM32 EABI5 soft-float cross build for the glibc 2.13/ARMv4T-compatible baseline	linux/amd64	latest, sha-<commit>	Inspect the pulled image
x64	ghcr.io/iotsharp/pcct-build-x64	Native X86-64 build with the aligned dependency and recognition stack	linux/amd64	latest, sha-<commit>	Inspect the pulled image
arm64	ghcr.io/iotsharp/pcct-build-arm64	AArch64 cross build with the aligned dependency and recognition stack	linux/amd64	latest, sha-<commit>	Inspect the pulled image
loongson	ghcr.io/iotsharp/pcct-build-loongson	LoongArch64/LA64 cross build with the aligned dependency and recognition stack	linux/amd64	latest, sha-<commit>	Inspect the pulled image
centos79	ghcr.io/iotsharp/pcct-build-centos79	Native X86-64 compatibility build for CentOS 7.9.2009 and glibc 2.17	linux/amd64	latest, 7.9, 7.9.2009, sha-<commit>	Inspect the pulled image

Pull all seven current images once:

docker pull ghcr.io/iotsharp/pcct-build-x86-legacy:latest
docker pull ghcr.io/iotsharp/pcct-build-x86:latest
docker pull ghcr.io/iotsharp/pcct-build-arm:latest
docker pull ghcr.io/iotsharp/pcct-build-x64:latest
docker pull ghcr.io/iotsharp/pcct-build-arm64:latest
docker pull ghcr.io/iotsharp/pcct-build-loongson:latest
docker pull ghcr.io/iotsharp/pcct-build-centos79:latest

GHCR package visibility is managed separately from the successful image push. If a package returns unauthorized or denied, either authenticate with an account whose token has read:packages, or have a package administrator make that package public. Do not treat the access error as a missing build or change the official image name.

After pulling, inspect the local architecture and Docker .Size value in bytes rather than relying on a documented estimate:

docker image inspect --format '{{index .RepoTags 0}} {{.Architecture}} {{.Size}}' \
  ghcr.io/iotsharp/pcct-build-x86-legacy:latest \
  ghcr.io/iotsharp/pcct-build-x86:latest \
  ghcr.io/iotsharp/pcct-build-arm:latest \
  ghcr.io/iotsharp/pcct-build-x64:latest \
  ghcr.io/iotsharp/pcct-build-arm64:latest \
  ghcr.io/iotsharp/pcct-build-loongson:latest \
  ghcr.io/iotsharp/pcct-build-centos79:latest

To remove an old local image, first list the installed tags, then enter one complete repository:tag reference. This removes only that tag. Do not use docker image prune, repository-wide deletion, or wildcard-generated removal lists when retaining latest and other published tags matters.

docker image ls --format 'table {{.Repository}}\t{{.Tag}}\t{{.ID}}' 'ghcr.io/iotsharp/pcct-build-*'
printf 'Exact repository:tag to remove: '
IFS= read -r old_image
docker image inspect "$old_image" >/dev/null && docker image rm "$old_image"

Image layout:

• sources/ stores the shared dependency version manifest, source-fetch helpers, target build scripts, the LaneApp LVGL profile, the pinned MiniGUI source archive, and the legacy ARM toolchain bundles.
• x86Legacy/ keeps the legacy Wheezy-based X86 debug image, including MiniGUI 2.0.4, SSH, and the old toolchain/debug baseline.
• x86/ is the independent LaneApp i386 compiler baseline: Ubuntu 16.04, GCC 5.4, glibc 2.23, Clang 6, MiniGUI 2.0.4, GDB/GDBServer, Valgrind, strace/ltrace, and GCC sanitizer runtimes.
• arm/ is the ARM32 LaneApp cross-compiler baseline: Ubuntu 16.04 host tools, GCC 5.4, legacy glibc 2.13, MiniGUI 2.0.4 rebuilt from the pinned source archive, EABI5 soft-float, ARMv4T-compatible code generation, and the same static plate-recognition API exposed by the X86 image.
• x64/ is the native X64 profile with the aligned static dependency and recognition stack.
• arm64/ is the AArch64 cross profile with the aligned static dependency and recognition stack.
• loongson/ is the LA64 cross profile with the aligned static dependency and recognition stack.
• centos79/ is the dedicated native X64 profile for the final CentOS 7.9.2009/glibc 2.17 baseline.

Shared dependency policy:

• All portable third-party dependencies are downloaded at build time from pinned GitHub release/tag archives and verified with SHA256 before extraction.
• Every aligned image pins curl 8.10.1, libxml2 2.12.10, freetype 2.13.3, libusb 1.0.23, sqlite 3.51.2, FFmpeg 4.4.5, PostgreSQL/libpq 17.2, mbedTLS 3.4.0, the LaneApp libpeer revision, and the LaneApp LVGL 9.3.0 profile.
• libusb stays pinned to 1.0.23 to preserve the conservative ARM32 source and runtime compatibility baseline.
• The ARM image wraps Ubuntu's GCC 5.4 cross compiler around the repository-owned legacy sysroot. Its image smoke test verifies the 32-bit EABI5 soft-float ABI, /lib/ld-linux.so.3, the glibc 2.13 ceiling, disabled FORTIFY calls, PostgreSQL's private static archives, and the target architecture and link closure of the recognition stack.
• sqlite stays aligned with the upstream app's 3.51.2 baseline so the image exposes a matching static libsqlite3.a, and it is fetched from the pinned GitHub mirror tag at image-build time like the other portable dependencies.
• The independent X86 image builds the LaneApp dependencies from pinned source archives and installs static libraries, headers, and pkg-config metadata under /usr/local. This includes the former LaneApp-private FFmpeg/VAAPI build chain, so LaneApp code changes do not rebuild these dependencies and LaneApp does not retain an FFmpeg submodule.
• Aligned-image curl keeps HTTPS enabled through the same mbedTLS 3.4.0 stack used by libpeer, libsrtp, and FFmpeg; IPv6 is disabled. OpenSSL 1.1.1w remains an optional source-build profile and is not installed by default, avoiding two TLS implementations in one LaneApp process.
• The X86 FFmpeg profile enables H.264 VAAPI against Xenial's libva/libdrm stack. FFmpeg remains static, while the hardware-facing i965 driver and its pinned 32-bit libva/libdrm runtime are exported at /opt/pcct/runtime/vaapi for LaneApp packaging.
• The X86, X64, ARM32, ARM64, LA64, and CentOS 7.9 LaneApp plate-recognition profiles pin OpenCV 4.5.1, MNN 2.2.0, and HyperLPR revision 9307450f7b7915be18f23a539ec05b41fe6629f4 (PCCT package 3.0.1.9307450.1). OpenCV contains only static core and imgproc; MNN is static CPU-only with one-thread scheduling; HyperLPR and all six verified MNN models are stored in libhyperlpr3.a. Every architecture also exposes the embedded NanoDet model through liblaneapp-nanodet.a. The extend-only HLPR_ContextObserveDetections ABI returns at most five pre-OCR-filter detector observations while preserving the existing update API. LaneApp builds use the same pkg-config contracts offline and add no recognition runtime shared library or model file. X86, ARM32, and CentOS 7.9 build the pinned CMake 3.14.7 host tool where their base-system CMake is too old; the modern Debian profiles use the distribution CMake.
• Recognition license, model hashes, patch hashes, capability metadata, and NOTICE records are installed below the target prefix in share/licenses, with the MNN and OpenCV license copies in adjacent versioned directories. The bounded HyperLPR patches and maintenance rules are documented in sources/HYPERLPR3.md; the pinned MNN toolchain patch adds the standard integer header and carries the upstream 2.2.1 ARM64 assembler fix, while sources/patches/mnn-2.2.0-i386-simd.patch remains specific to i386 SSE4.1/AVX2/FMA dispatch. The legacy ARMv4T profile intentionally selects MNN's portable scalar CPU path instead of ARMv7 NEON assembly.
• Every aligned image links curl, libxml2, FFmpeg, libpeer/libsrtp, mbedTLS, libpq, libusb, and the LaneApp LVGL profile into a target-architecture smoke binary. Verification also cross-links HyperLPR and NanoDet consumers and rejects recognition shared libraries or loose runtime model files. X86 retains its explicit VAAPI runtime checks, ARM32 retains its EABI5/glibc 2.13 checks, LA64 retains its toolchain checks, and CentOS 7.9 enforces the glibc 2.17 ceiling.
• All images build MiniGUI 2.0.4 from the repository-owned source archive; none reuse MiniGUI build artifacts from another image or from the legacy ARM sysroot.
• CentOS 7 is EOL. The dedicated image pins the final 7.9.2009 base image and archived package repositories; it is a compatibility target, not a source of ongoing security updates.
• The CentOS profile uses the archived Developer Toolset 7 compiler because MNN requires GCC 4.9 or newer. Linked verification keeps the CentOS glibc 2.17 ceiling and rejects dynamic recognition or C++ runtime dependencies.

Batch build with Docker Compose:

• docker-compose.yml can start all build images in parallel and bind-mount a host source directory into /LaneApp.
• docker-compose.yml is the runtime entrypoint and pulls prebuilt images from GHCR by default.
• docker-compose.override.yml only carries the local build definitions. When you run docker compose up --build, Compose uses the override and rebuilds the images locally before starting them.
• Set BUILD_DIR to the host directory you want to build, and optionally set BUILD_COMMAND (defaults to make).
• Optionally set PCCT_IMAGE_PREFIX (defaults to ghcr.io/iotsharp) and PCCT_IMAGE_TAG (defaults to latest) to switch image registry/tag.
• The CentOS image also publishes moving 7.9 and 7.9.2009 aliases. Use a CentOS-specific tag only together with --targets centos79; the other image repositories publish latest and immutable sha-<commit> tags.
• The repo root also provides compose-up-all.cmd and compose-up-all.sh wrapper scripts so you do not have to export the environment variables manually each time.
• The wrapper scripts default to pull mode, which only uses docker-compose.yml and pulls remote images. Pass --build or --mode build to add docker-compose.override.yml and rebuild the images locally.
• The wrapper scripts default to the all target set. You can narrow a run with --targets, for example x64, arm64, centos79, or x86 x64. Supported targets are x86legacy, x86, arm, x64, arm64, loongson, and centos79.
• PowerShell example: $env:BUILD_DIR='D:/path/to/project'; $env:BUILD_COMMAND='make'; docker compose up --build
• Bash example: BUILD_DIR=/abs/path/to/project BUILD_COMMAND=make docker compose up --build
• Windows cmd examples: compose-up-all.cmd D:\path\to\project compose-up-all.cmd D:\path\to\project --targets x64,arm64 compose-up-all.cmd D:\path\to\project "cmake --build build" --build --targets x86,x64 compose-up-all.cmd D:\path\to\project --mode build --targets all -- --abort-on-container-exit
• Linux/macOS sh examples: sh ./compose-up-all.sh /path/to/project sh ./compose-up-all.sh /path/to/project --targets x64,arm64 sh ./compose-up-all.sh /path/to/project "cmake --build build" --build --targets x86,x64 sh ./compose-up-all.sh /path/to/project --mode build --targets all -- --abort-on-container-exit
• The compose run exits after all service commands finish. Build outputs stay in the mounted host directory.

Legacy VisualGDB debug entrypoint:

• Start the local debug builder with docker compose -f docker-compose.debug.yml up --build -d x86-debug-builder
• The container exposes SSH on 127.0.0.1:2221, which matches LaneApp-Debug.vgdbsettings
• x86Legacy still keeps the MiniGUI 2.0.4, SSH, and dual-target arm + x86 legacy workflow; the other images use the aligned dependency stack.