Investigate reducing size of /opt/llvm directory in crossdeps-builder

[mthalman]

There are a ton of binaries that get installed into the /opt/llvm directory in the crossdeps-builder images, adding up to about 4 GB. This then gets passed on to the crossdeps-llvm image which copies the contents of that directory into its own image:

dotnet-buildtools-prereqs-docker/src/azurelinux/3.0/net10.0/crossdeps-llvm/amd64/Dockerfile

Line 8 in ef1b7e8

COPY --from=builder /opt/llvm /usr/local

And then there are a bunch of cross images based on crossdeps-llvm. So you're left with a bunch of images that, when loaded, take up a lot of disk space. This is problematic for the SBOM generation of the build because it has to load each one of these images and scan them. This is very costly: #1435.

There should be an investigation to determine which of the files in the /opt/llvm directory are actually required and delete everything else.

/cc @sbomer

[sbomer]

@am11 might have an idea which of these are needed and which are not. Some relevant context: #832 (comment).

[mthalman]

@am11 - Do you have any insight on which of these files are actually required in the build?

[am11]

The crossdeps-builder Dockerfile builds a host-targeted LLVM toolchain with support for cross-compiling to multiple architectures (like riscv64, arm64, etc.), and sets up rootfs build scripts.

In contrast, each cross/{arch} Dockerfile (e.g., cross/riscv64) uses that toolchain to cross-compile architecture-specific LLVM runtimes (like libc++ and compiler-rt) into a clean layer, using unique rootfs for that target platform.

This is problematic for the SBOM generation of the build because it has to load each one of these images and scan them.

If that's the primary concern, could we limit SBOM scanning to just the final/exported layer and skip intermediate ones? That would reduce scanning overhead without losing essential metadata.

Determining what's actually needed in the final image isn't trivial; the list of installed files is controlled by LLVM's CMake logic. While we might be able to insert a probe to capture this, it would likely require a custom solution with a high risk of bugs and divergence from upstream behavior.

[mthalman]

If that's the primary concern, could we limit SBOM scanning to just the final/exported layer and skip intermediate ones?

The SBOM scanning isn't the primary concern anymore. That is being mitigated with a different approach that won't be that impacted by the size of these images.

Determining what's actually needed in the final image isn't trivial

In that case, I think it's fine to just close this.