When I do a release build, it can't find my executable when it tries to launch the container

Technical Support
, , , , ,
1

So, I am trying to build a release build using the task: run-container-torizon-release-arm64. However, when it gets to the end where it tries to spin up the container, it says it can’t find the executable.

“Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: “./app/MyApp -D”: stat ./app/MyApp -D: no such file or directory: unknown”

My makefile is virtually the same as the helloworld app with the exceptions of hardware needs and more files. It compiles and creates the debug version just fine. After it stops, I look for any executable in my working directory and there is none.
Not really sure where is is putting it, if it actually links it.

Thanks,*

Steve

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I’d be glad to help troubleshoot your release build issue! Could you let me know which OS and version you are running, and which hardware platform you’re using? You can run the tdx-info command to get detailed information about your setup - more details at tdx-info documentation.

This information will help me provide the most accurate guidance for your specific configuration.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Software summary

Bootloader: U-Boot

Kernel version: 6.6.94-7.3.0-g5a62539de8f9 #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 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/5c84b03643fe3e8b7be49b13c2171a7f45d0dce855097b9fafed3f75e9260a47/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-build.18
Distro variant: VARIANT=“Docker”
Hostname: verdin-imx8mp-15132709

Hardware info

HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board

Toradex version: 0058 V1.1A
Serial number: 15132709
Processor arch: aarch64

4

Thanks for providing the system information! I can see you’re running Torizon OS 7.3.0-build.18 on a Verdin iMX8M Plus. The error indicates the container can’t find the executable file at the expected location.

Understanding the Container Structure

For release builds, the Torizon IDE Extension uses a multi-stage build process (1). The release container defined by Dockerfile includes:

  • A build container that compiles code (identified by as Build alias)
  • A runtime container that executes on the SoM (identified by as Deploy alias)

The compiled code is copied from the build to the runtime container through a COPY command (1):

COPY --from=Build ${APP_ROOT}/build-${IMAGE_ARCH}/bin ${APP_ROOT}

Troubleshooting Steps

1. Check Your Dockerfile Structure

Verify that your Dockerfile properly copies the executable from the build stage to the runtime stage (1). The APP_ROOT variable is defined in .vscode/settings.json and sets the directory where build files are copied (1).

2. Verify Build Output Location

The build process should place executables in the build-${IMAGE_ARCH}/bin subdirectory (2). For ARM64, this would be build-arm64/bin (2). Check if your Makefile is outputting the executable to this expected location.

3. Check Container Image Build

Since the debug version works but release fails, compare:

  • Your Dockerfile.debug vs Dockerfile
  • Ensure both are copying files from the correct build directories

4. Examine the Multi-stage Build

The multi-stage build guarantees the same environment for compilation and optimizes the container image (1). Make sure your Dockerfile properly defines both the build and deploy stages.

Common Issue Resolution

Based on similar issues in the community (3), verify that your docker-compose.yml and task configurations are properly set up with the correct environment variables and image references.

The fact that debug works suggests your build process is correct, but the release container might not be copying the executable to the expected runtime location.

**

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

@eric.tx @ToradexAI
So, after the debug version, there are files in my build-arm64/debug directory that are the object and the executable. When I run the “release” build, there is nothing in the build-arm64/bin build-arm64/obj directories. In fact, if I delete the entire directory, it still builds all the way to the end and fails because there is no executable in the final container. There is no error when it is copying the executable, so I am assuming that it actually works, since I can’t verify anything being inside the container.

Steve

6

@ToradexAI
@eric.tx
So, after looking at the Hello World version and my version of the makefile, I noticed something. The release build is not set up the same as debug, which is why it appears that it is building a debug version in both cases. Here is the debug & release versions of the makefile in HW:
$(TARGET_DEBUG): $(OBJ_DEBUG)
$(CC) $(CCFLAGS) $(DBGFLAGS) $(OBJ_DEBUG) -o $@ $(LDFLAGS)

$(TARGET): $(OBJ)
$(CC) $(CCFLAGS) -o $@ $(OBJ) $(LDFLAGS)

I don’t think the release is correct since it isn’t the same as the debug version for linking. The $(OBJ) should be before the -o.
This leads me to believe that it is not using the release build of the makefile. Am I incorrect?

Steve

7

You’re absolutely correct in your analysis! The issue is indeed with your Makefile configuration. The release build isn’t producing any output because the linking command syntax is incorrect.

The Problem

You’ve identified the key issue - the release target in your Makefile has the wrong order of arguments. The correct syntax should place the object files before the -o flag, just like in the debug version.

Correct Makefile Structure

Based on the Torizon IDE Extension documentation (1), the Makefile should follow this pattern:

Debug target (correct):

$(TARGET_DEBUG): $(OBJ_DEBUG)
	$(CC) $(CCFLAGS) $(DBGFLAGS) $(OBJ_DEBUG) -o $@ $(LDFLAGS)

Release target (should be):

$(TARGET): $(OBJ)
	$(CC) $(CCFLAGS) $(OBJ) -o $@ $(LDFLAGS)

Your current release target has $(OBJ) after the -o $@, which is incorrect and likely causing the linker to fail silently or not produce the expected output.

Why This Happens

The Torizon IDE Extension uses different build configurations for debug and release builds (1). The debug container and release container have different build processes:

  • Debug builds place executables in the build-arm64/debug directory
  • Release builds should place executables in the build-arm64/bin directory (1)

Since your release Makefile target isn’t linking correctly, no executable is being created, which explains why the build-arm64/bin directory remains empty.

Solution

Fix your Makefile release target to match the correct linking order:

$(TARGET): $(OBJ)
	$(CC) $(CCFLAGS) $(OBJ) -o $@ $(LDFLAGS)

This should resolve the issue and allow your release build to properly create the executable in the expected location for the container to find it.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

8

@ToradexAI
@eric.tx

OK I fixed that, only I still have no executable that will run according to the error I get.
This line in the Dockerfile doesn’t look right to me:

# Copy the application compiled in the build step to the $APP_ROOT directory

path inside the container, where $APP_ROOT is the torizon_app_root

configuration defined in settings.json

COPY --from=build ${APP_ROOT}/build-${IMAGE_ARCH}/bin ${APP_ROOT}
it is using $(APP_ROOT) in both to and from and the $(APP_ROOT) is supposed to be defined in my settings.json file, which it isn’t. I don’t have any CAPITALIZZED definitions there. But the base concept is wrong since the $(APP_ROOT) is meant to be a path inside the container we are going to be running from.

Steve

9

You’re correct to question that COPY command! The issue is with the variable reference format and the missing configuration.

The Problem

The COPY command you’re seeing is using the wrong variable syntax and referencing a configuration that should exist in your .vscode/settings.json file.

Correct Variable Configuration

According to the Torizon IDE Extension documentation (1), the APP_ROOT variable should be defined in .vscode/settings.json. This variable sets the directory where build files are copied (1).

The correct COPY command should look like this (1):

COPY --from=Build ${APP_ROOT}/build-${IMAGE_ARCH}/bin ${APP_ROOT}

Missing Configuration

You mentioned that you don’t have any capitalized definitions in your settings.json file. You should have a torizon_app_root setting defined there. Check your .vscode/settings.json file for something like:

{
    "torizon_app_root": "/home/torizon/app"
}

How Variables Work

The documentation explains that (1):

  • The APP_ROOT variable is defined in .vscode/settings.json
  • It sets the directory to which the build files are copied
  • The value for IMAGE_ARCH is automatically set according to the target’s architecture (e.g., IMAGE_ARCH=arm64 for ARM64)

Resolution Steps

  1. Check your .vscode/settings.json file for the torizon_app_root configuration
  2. Verify your Dockerfile uses the correct variable syntax: ${APP_ROOT} not $(APP_ROOT)
  3. Ensure the build process is placing your executable in build-arm64/bin/ directory (1)

The multi-stage build copies compiled code from the build container to the runtime container through this COPY command (1), so getting the paths correct is crucial for the container to find your executable.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

10

In the paragraph I wrote for the explanation, I did have () around APP_ROOT. But the actual statement above that is/was correct.
So, I tried adding this line to see what was in the build path:
RUN ls ${APP_ROOT}/build-${IMAGE_ARCH}/bin

It ran, but said there was no such path. I also ran this command:
RUN ls /home/torizon/app
and got no output, so I think there was nothing copied, which is why my container is failing to actually start.

Steve

11

Please explain in detail what this command in the Dockerfile (not Dockerfile.debug version) is doing. I put a RUN ls ${APP_ROOT}/build-${IMAGE_ARCH}/bin which errors out of the build just before my Makefile is called. So there is no build from that.