Inspiration
Cross-development handovers can pair plausible compiler commands with the wrong CPU artifact, or accidentally ship a native Linux executable. A filename or architecture label alone does not prove a QNX build. SyntraVariga / AhaWissenschaft makes this narrow consistency check explicit and reproducible.
What it does
This local Python host tool compares explicit QNX qcc/q++ target declarations, an expected x86_64 or aarch64le delivery target, and bounded ELF header/interpreter evidence. It reports CONSISTENT_IN_SCOPE (exit 0), CONFLICT (exit 1), or INCOMPLETE/input error (exit 2). It never executes the commands or target binary, follows response files, or opens source/dependency paths from the database. JSON reports redact source paths and command text and identify the supplied bytes with SHA-256.
Meaningful QNX connection
qnxguard.py relates documented gcc_ntox86_64/gcc_ntoaarch64le qcc selectors and QNX loader path evidence to an explicit delivery target. This is a host-side analysis tool intended to support QNX cross-development. It does not need to run on QNX itself. The checked QNX pathnames and selectors are documented in the linked official QNX SDP 8.0 references in the README.
How it was built
New standalone Python 3 code with standard-library JSON, shlex, struct, argparse, hashlib and unittest. Built with AI coding and bounded review assistance, with human direction from AhaWissenschaft. No private SyntraVariga engine or proprietary QNX SDK binaries are included. MIT-licensed public source, tests, examples and build/run instructions are available in the linked repository.
Evidence and reproduction
Tested host: Linux / Python 3.12.14. At release, 33 local unittest methods passed. An independent agent spot-check found option-operand, selector-grammar and multiline-shell parser defects; regression cases reproduced them and passed after fixes. This is local evidence, not external certification.
Run: python3 examples/make_demo.py python3 qnxguard.py examples/compile_commands.json --target aarch64le --elf examples/structural-aarch64.elf python3 -m unittest discover -s tests -v
The matching structural fixture returns CONSISTENT_IN_SCOPE. Supplying structural-x86_64.elf for the same aarch64le target produces ELF_MACHINE_MISMATCH and exit 1. A separately compiled owned native Linux C++ example provides a genuine negative control; its binary is inspected, not executed.
Challenges and lessons
Conservative uncertainty handling matters: absent interpreter fields, implicit SDK defaults, response files and unsupported wrappers must not silently pass. A QNX loader pathname is evidence about bytes, not proof of provenance. The parser therefore reports incompleteness and retains explicit NOT_PROVEN/NOT_VERIFIED fields.
Limits and next validation
Positive structural fixtures are synthetic ELF headers, not functioning QNX executables or genuine SDK output. Authentic QNX SDP-produced output has not yet been validated. No QNX8 runtime, ABI, safety, timing, functionality or artifact-provenance guarantee is claimed. SHA-256 identifies bytes, not correctness. This is an engineering prototype and a narrow evidence check, not a complete compiler-driver or ELF validator. Next validation is an authorized authentic QNX8 artifact and associated compilation database, with the same positive/negative controls. No prize, payment or organizer endorsement is claimed.
Brand
SyntraVariga / AhaWissenschaft. Not affiliated with QNX, BlackBerry or Devpost. See README and LICENSE for reproducible scope and attribution.
