I’m trying to build application software for torizon-minimal built from scarthgap-7.x.y using the instructions at Build Torizon OS from Source With Yocto Project/OpenEmbedded | Toradex Developer Center , and the aarch64-tdx-linux cross-compiler produced by this build seems…incomplete.
If I source setup-environment, it augments my PATH so I can run aarch64-tdx-linux-gcc and the rest of the gcc front-ends. When I try to compile a simple hello-world.c, though, I get the following error:
as: unrecognized option ‘-EL’
The obvious conclusion is that aarch64-tdx-linux-gcc is invoking the system’s native “as” rather than “aarch64-tdx-linux-as”, which I confirmed via strace and “aarch64-tdx-linux-gcc -dumpspecs”. When I started digging into the work area for the Torizon build, I found a few “as” front-ends that turned out to be broken symlinks to an “aarch64-tdx-linux-as” front-end. I also found a few “aarch64-tdx-linux-as” front-ends, but apparently the cross-binutils front-ends are simply not in the PATH augmented by setup-environment.
If I manually set up the PATH to include cross-binutils front-ends, then I find aarch64-tdx-linux-gcc still needs a manual “–sysroot” option to point to a usable sysroot…and even then it’s still having trouble locating some of the crt*.o objects.
So my question now is, should we expect setup-environment to provide a PATH to a cross-toolchain that works out-of-box without all this hackery? Am I missing something simple and silly here? I understand we’re targeting a somewhat bleeding-edge dev board, but I would think Torizon has had general aarch64 cross-compiler support for a while now, and it obviously produced a cross-compiler that was usable by bitbake recipes. For the moment I’m working to generate a scarthgap-7.1 image to see if its toolchain is more usable (and of course I can always build a vanilla toolchain from scratch), but it’s a bit of a speed bump to our development.
For background, tdx-info says:
Software summary
Bootloader: U-Boot
Kernel version: 6.6.84-7.2.0-devel-g8bf00740f043 #1-Torizon SMP PREEMPT Thu Mar 27 16:42:10 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/cab77ab08b74a6aaaaf11e1789d0dae2d8fcecdead853b841e6b8d43a71c7eb5/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.2.0-devel-20250407145936-build.0
Distro variant: VARIANT=“Minimal”
Hostname: aquila-am69-12593347
Hardware info
HW model: Toradex Aquila AM69 on Aquila Development Board
Toradex version: 0088 V1.0A
Serial number: 12593347
Processor arch: aarch64
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello there!
Torizon OS 7 is indeed built on Toradex BSP 7, which utilizes NXP BSP 6.6.y. For development, Toradex recommends using containers with SDK toolchains to cross-compile code for System on Module (SoM) architectures. This approach is well-documented and helps manage cross-compilation while keeping build files organized within the project workspace.
To address the toolchain configuration issues you might be facing, I suggest the following steps:
- SDK Container Approach: Utilize the SDK container method as documented for Torizon. This approach simplifies cross-compilation and helps avoid configuration issues.
- Docker Compose Configuration: Use a
docker-compose.yml file to set up your build parameters effectively.
- Dockerfile.sdk Implementation: Implement your build process through
Dockerfile.sdk, which is designed to handle the cross-compilation environment efficiently.
Unfortunately, I can’t provide specific troubleshooting steps for bare metal cross-compiler issues, as the documentation doesn’t cover this scenario. However, if you need more information on the containerized SDK approach, feel free to ask!
Best regards,
Toradex AI Assistant
Greetings @jarndraugr,
Thank you for reporting this. To be honest we are not currently checking the state of the toolchain produced from Yocto for Torizon-minimal, especially for every machine. This is probably something we’ll need to manually check ourselves to understand what Yocto is doing here when producing this toolchain.
Just to have the full story here. What exactly did you do in your build to produce the problematic cross-toolchain? I can gather you did the source setup-environment to setup the build environment, but then what did you do from there exactly? We just want to make sure we have a full view of what you did.
Best Regards,
Jeremias
I’m mostly following the documented steps, with the exception of enabling some extra packages, then augmenting torizon-static-passwd and torizon-static-group to satisfy the extra package requirements.
A condensed excerpt of the script I’m using ($TZROOT refers to our Torizon build directory, and $MC11ROOT refers to our “source” directory with extra content):
cd "${TZROOT}" &&
repo init -u 'git://git.toradex.com/toradex-manifest.git' -b scarthgap-7.x.y -m torizon/default.xml &&
repo sync --no-clone-bundle &&
MACHINE=aquila-am69 source setup-environment &&
cp -v "${MC11ROOT}/kasctl/local.conf" "${MC11ROOT}/kasctl/bblayers.conf" "${TZROOT}/layers/meta-toradex-torizon/conf/template/" &&
mkdir -p "${TZROOT}/build-torizon/conf" &&
cp -v "${MC11ROOT}/kasctl/local.conf" "${MC11ROOT}/kasctl/bblayers.conf" "${TZROOT}/build-torizon/conf/" &&
echo "Updating torizon-static-passwd and torizon-static-group..." &&
cat "${MC11ROOT}/kasctl/kasctl-static-passwd" "${TZROOT}/layers/meta-toradex-torizon/files/torizon-static-passwd" | sort -n -t ':' -k3 -u > "${MC11ROOT}/kasctl/merged-static-passwd" &&
cat "${MC11ROOT}/kasctl/kasctl-static-group" "${TZROOT}/layers/meta-toradex-torizon/files/torizon-static-group" | sort -n -t ':' -k3 -u > "${MC11ROOT}/kasctl/merged-static-group" &&
mv "${MC11ROOT}/kasctl/merged-static-passwd" "${TZROOT}/layers/meta-toradex-torizon/files/torizon-static-passwd" &&
mv "${MC11ROOT}/kasctl/merged-static-group" "${TZROOT}/layers/meta-toradex-torizon/files/torizon-static-group" &&
bitbake torizon-minimal
I’ve uploaded our modified local.conf, bblayers.conf, and static passwd/group entries for reference, just in case any of that matters.
bblayers.conf (1.7 KB)
kasctl-static-group (69 Bytes)
kasctl-static-passwd (122 Bytes)
local.conf (5.3 KB)
FYI the resulting Torizon image consistently seems to load and run fine on our dev board. Also, when we fire up a Dockerfile.sdk image and use the toolchain within there, we seem to have no problems building applications and running them on the target.
Just to clarify it’s the toolchain/sdk you’re having issues with, correct?
Your script stops at bitbake torizon-minimal. I would imagine you are also executing bitbake torizon-minimal -c populate_sdk, correct?
If that is the case, then does that work for you? When I try to build the toolchain/sdk I get a build error, with our default configuration. So I’m wondering how you got around this since I don’t see anything in your configs that would get around the build issue I saw.
Best Regards,
Jeremias
Ah, that’s it. I never did the populate_sdk step. I figured it was something that simple. 
The bad news is, as you mentioned, the default configuration has some build errors, primarily around aktualizr packages.
The good news is, for our product use-case, I managed to build a complete-enough SDK for or use by simply excluding the aktualizr packages. And this is likely a useful detail for anyone else trying to generate an SDK from the default configuration.
The good news is, for our product use-case, I managed to build a complete-enough SDK for or use by simply excluding the aktualizr packages. And this is likely a useful detail for anyone else trying to generate an SDK from the default configuration.
That’s good to hear you are unblocked at least for your use-case. It was also useful for us to know there was an issue here in the first place since we rarely run the populate_sdk step.
With all that said, sounds like you are good here now correct? Or do you have further questions/issues related to this topic?
Best Regards,
Jeremias
