Building and running Bazel applications on AutoSD: Toolchains, containers, and recommended practices

Bazel is an open source build system that automates software builds and tests. Supported build tasks include running compilers and linkers to produce executable programs and libraries, and assembling deployable packages. Similar to tools like Make, Ant, Gradle, and Maven, Bazel supports multiple languages, repositories, and platforms in an industry-leading ecosystem. Reproducibility, scalability, and cross-platform consistency are key design goals of Bazel's hermetic and declarative build model, which has driven its adoption among original equipment manufacturers (OEMs). This article explores practical approaches for building and running Bazel applications on Automotive Stream Distribution (AutoSD), focusing on toolchain integration and reproducible environments.

Integrating platform-specific environments like AutoSD with Bazel is challenging because Bazel requires explicit configuration of toolchains, including compilers and system dependencies. This complexity is particularly acute when targeting embedded or specialized runtime ecosystems.

There are three practical approaches to building and running Bazel applications on AutoSD: A native AutoSD GCC toolchain, an abstracted S-CORE toolchain, and a container-based environment.

Approach 1: Native AutoSD GCC toolchain

This approach uses a GCC toolchain configured for AutoSD. It integrates directly with Bazel by registering a platform-specific toolchain and explicitly defining compilation flags.

When to use

Use this method when:

• You are targeting AutoSD exclusively
• You want minimal abstraction and direct control over compiler behavior
• Your setup does not require multi-platform portability

Setup

Start by declaring the AutoSD dependency and configuring the toolchain in MODULE.bazel:

bazel_dep(name = "os_autosd", version = "1.0.0")
git_override(
    module_name = "os_autosd",
    remote = "https://github.com/eclipse-score/inc_os_autosd",
    commit = "a78e559cf81754c199c926229dc6b4443e1ff149",
 )

autosd_10_gcc = use_extension("@os_autosd//toolchain/autosd_10_gcc:extensions.bzl", "autosd_10_gcc_extension")
autosd_10_gcc.configure(
    c_flags = ["-fPIC"],
    cxx_flags = ["-fPIC"],
)

use_repo(autosd_10_gcc, "autosd_10_gcc_repo")

This configuration registers the AutoSD GCC toolchain and applies the required compilation flags for C and C++ targets.

Build execution

You can invoke the build using the toolchain with the bazel command:

bazel build //... --extra_toolchains=@autosd_10_gcc_repo//:gcc_toolchain_linux_x86_64

Alternatively, define it in a .bazelrc file:

build --extra_toolchains=@autosd_10_gcc_repo//:gcc_toolchain_linux_x86_64

Then run:

bazel build //...

Advantages

• Simple and explicit configuration
• Minimal abstraction

Limitations

• Tightly coupled to AutoSD
• Not suitable for multi-platform builds
• Requires duplication if additional platforms are introduced
• Potential runtime incompatibilities (for example, glibc version mismatches) if the build environment diverges from the target AutoSD runtime
• Requires host dependencies (rpm2cpio and cpio) to extract RPM packages used for toolchain setup

Approach 2: S-Core abstracted GCC toolchain

The S-Core toolchain provides an abstraction layer over multiple supported platforms, such as AutoSD and QNX. Instead of binding builds to a single environment, this approach defines a unified toolchain interface that Bazel can use to target different runtime ecosystems through platform configuration.

When to use

Use this method when:

• You need to support multiple target platforms (for example, AutoSD, QNX)
• You want a standardized toolchain strategy for CI/CD pipelines
• You aim to minimize platform-specific build logic in application code

Setup

Begin by declaring the S-Core toolchain dependency and configuring the GCC toolchain extension in MODULE.bazel:

bazel_dep(name = "score_bazel_cpp_toolchains", version = "0.4.0")

git_override(
    module_name = "score_bazel_cpp_toolchains",
    remote = "https://github.com/eclipse-score/bazel_cpp_toolchains.git",
    commit = "e3383755e166262b7d647608d26dfb0ae9895c93",
)

bazel_dep(name = "score_bazel_platforms", version = "0.1.0")

gcc = use_extension("@score_bazel_cpp_toolchains//extensions:gcc.bzl", "gcc")

gcc.toolchain(
    name = "score_autosd_10_toolchain",
    target_cpu = "x86_64",
    target_os = "linux",
    runtime_ecosystem = "autosd10",
    use_default_package = True,
)

use_repo(gcc, "score_autosd_10_toolchain")

register_toolchains("@score_autosd_10_toolchain//:x86_64-linux-autosd10")

This configuration defines a reusable toolchain that abstracts the underlying AutoSD-specific details while remaining compatible with other supported platforms.

Build execution

To build using this toolchain, specify the corresponding platform:

bazel build //... --platforms=@score_bazel_platforms//:x86_64-linux-autosd10

Alternatively, define it in .bazelrc:

build --platforms=@score_bazel_platforms//:x86_64-linux-autosd10

Then run:

bazel build //... 

Advantages

• Enables multi-platform builds with a single configuration
• Well-suited for CI/CD environments and automated testing
• Reduces duplication of toolchain definitions

Limitations

• Adds an abstraction layer that might obscure low-level configuration
• Requires alignment with S-Core conventions and ecosystem
• Potential runtime incompatibilities (such as glibc version mismatches) if the build environment diverges from the target AutoSD runtime

Approach 3: Containerized AutoSD build environment

This approach encapsulates the AutoSD build environment inside a container image with all required dependencies pre-installed, including GCC and Bazel. Instead of configuring a Bazel toolchain explicitly, Bazel uses the toolchain available within the container's runtime environment. You might need to double check whether you have a local .bazelrc file forcing any particular toolchain for your project.

This method emphasizes reproducibility and isolation by standardizing the build environment across developers and CI systems.

When to use

Use this method when:

• You need fully consistent development builds and CI environments across machines. You want to avoid complex Bazel toolchain configuration
• You are already using container-based workflows (for example, CI pipelines)

Setup

Create a container image with the required build dependencies. Below is a minimal example:

FROM quay.io/centos/centos:stream10

RUN dnf update -y && \
    dnf install -y \
        wget \
        ca-certificates \
        unzip \
        which \
        gcc \
        gcc-c++ \
        libstdc++ \
        libstdc++-devel \
        rpm \
        cpio \
        java-21-openjdk-devel \
        git \
        rpm-build

RUN wget https://github.com/bazelbuild/bazel/releases/download/8.6.0/bazel-8.6.0-installer-linux-x86_64.sh

RUN chmod +x ./bazel-8.6.0-installer-linux-x86_64.sh && ./bazel-8.6.0-installer-linux-x86_64.sh

RUN rm -f ./bazel-8.6.0-installer-linux-x86_64.sh

# Verify installation
RUN bazel --help

CMD ["/bin/bash"]

Note: Some projects may require a specific Bazel version, so in that case the installed version in the container here would need to be adjusted.

Build the container image:

podman build -t localhost/bazel_autosd10:latest .

Build execution

Run Bazel inside the container while mounting your workspace and cache:

podman run --rm \-v "$(pwd)":/workspace:Z \-v "$HOME/.cache/bazel:/root/.cache/bazel:Z" \-w /workspace \localhost/bazel_autosd10:latest \bash -c "bazel build //..."

Advantages

• Strong environment consistency
• Minimal Bazel-specific configuration required
• Easy integration into CI/CD platforms
• Simplifies onboarding for new developers
• Controlled and consistent runtime environment, reducing the risk of glibc or system library mismatches

Limitations

• Less explicit control over Bazel toolchain resolution
• Potential mismatch between container and target runtime (if not carefully managed)
• Might introduce overhead in build startup time

Conclusion

Each approach offers different tradeoffs for building applications with Bazel on AutoSD. The project GitHub repository contains all three implementations, providing a practical starting point for exploring and adopting these setups.