Creating a Conan package for a toolchain

After learning how to create recipes for tool requires that package applications, we are going to show an example on how to create a recipe that packages a precompiled toolchain or compiler for building other packages.

In the “How to cross-compile your applications using Conan: host and build contexts” tutorial section, we discussed the basics of cross-compiling applications using Conan with a focus on the “build” and “host” contexts. We learned how to configure Conan to use different profiles for the build machine and the target host machine, enabling us to cross-compile applications for platforms like Raspberry Pi from an Ubuntu Linux machine.

However, in that section, we assumed the existence of a cross-compiling toolchain or compiler as part of the build environment, set up through Conan profiles. Now, we will take a step further by demonstrating how to create a Conan package for such a toolchain. This package can then be used as a tool_require in other Conan recipes, simplifying the process of setting up the environment for cross-compilation.

Please, first clone the sources to recreate this project. You can find them in the examples2 repository on GitHub:

  1. $ git clone https://github.com/conan-io/examples2.git
  2. $ cd examples2/examples/cross_build/toolchain_packages/toolchain

Here, you will find a Conan recipe (and the test_package) to package an ARM toolchain for cross-compiling to Linux ARM for both 32 and 64 bits. To simplify a bit, we are assuming that we can just cross-build from Linux x86_64 to Linux ARM, both 32 and 64 bits. If you’re looking for another example, you can explore an additional MacOs to Linux cross-build example right here .

  1. .
  2. ├── conanfile.py
  3. └── test_package
  4.     ├── CMakeLists.txt
  5.     ├── conanfile.py
  6.     └── test_package.cpp

Let’s check the recipe and go through the most relevant parts:

conanfile.py

  1. import os
  2. from conan import ConanFile
  3. from conan.tools.files import get, copy, download
  4. from conan.errors import ConanInvalidConfiguration
  5. from conan.tools.scm import Version
  7. class ArmToolchainPackage(ConanFile):
  8.     name = "arm-toolchain"
  9.     version = "13.2"
  10.     ...
  11.     settings = "os", "arch"
  12.     package_type = "application"
  14.     def _archs32(self):
  15.         return ["armv6", "armv7", "armv7hf"]
  17.     def _archs64(self):
  18.         return ["armv8", "armv8.3"]
  20.     def _get_toolchain(self, target_arch):
  21.         if target_arch in self._archs32():
  22.             return ("arm-none-linux-gnueabihf",
  23.                     "df0f4927a67d1fd366ff81e40bd8c385a9324fbdde60437a512d106215f257b3")
  24.         else:
  25.             return ("aarch64-none-linux-gnu",
  26.                     "12fcdf13a7430655229b20438a49e8566e26551ba08759922cdaf4695b0d4e23")
  28.     def validate(self):
  29.         if self.settings.arch != "x86_64" or self.settings.os != "Linux":
  30.             raise ConanInvalidConfiguration(f"This toolchain is not compatible with {self.settings.os}-{self.settings.arch}. "
  31.                                             "It can only run on Linux-x86_64.")
  33.         valid_archs = self._archs32() + self._archs64()
  34.         if self.settings_target.os != "Linux" or self.settings_target.arch not in valid_archs:
  35.             raise ConanInvalidConfiguration(f"This toolchain only supports building for Linux-{valid_archs.join(',')}. "
  36.                                         f"{self.settings_target.os}-{self.settings_target.arch} is not supported.")
  38.         if self.settings_target.compiler != "gcc":
  39.             raise ConanInvalidConfiguration(f"The compiler is set to '{self.settings_target.compiler}', but this "
  40.                                             "toolchain only supports building with gcc.")
  42.         if Version(self.settings_target.compiler.version) >= Version("14") or Version(self.settings_target.compiler.version) < Version("13"):
  43.             raise ConanInvalidConfiguration(f"Invalid gcc version '{self.settings_target.compiler.version}'. "
  44.                                                 "Only 13.X versions are supported for the compiler.")
  46.     def source(self):
  47.         download(self, "https://developer.arm.com/GetEula?Id=37988a7c-c40e-4b78-9fd1-62c20b507aa8", "LICENSE", verify=False)
  49.     def build(self):
  50.         toolchain, sha = self._get_toolchain(self.settings_target.arch)
  51.         get(self, f"https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-{toolchain}.tar.xz",
  52.             sha256=sha, strip_root=True)
  54.     def package_id(self):
  55.         self.info.settings_target = self.settings_target
  56.         # We only want the ``arch`` setting
  57.         self.info.settings_target.rm_safe("os")
  58.         self.info.settings_target.rm_safe("compiler")
  59.         self.info.settings_target.rm_safe("build_type")
  61.     def package(self):
  62.         toolchain, _ = self._get_toolchain(self.settings_target.arch)
  63.         dirs_to_copy = [toolchain, "bin", "include", "lib", "libexec"]
  64.         for dir_name in dirs_to_copy:
  65.             copy(self, pattern=f"{dir_name}/*", src=self.build_folder, dst=self.package_folder, keep_path=True)
  66.         copy(self, "LICENSE", src=self.build_folder, dst=os.path.join(self.package_folder, "licenses"), keep_path=False)
  68.     def package_info(self):
  69.         toolchain, _ = self._get_toolchain(self.settings_target.arch)
  70.         self.cpp_info.bindirs.append(os.path.join(self.package_folder, toolchain, "bin"))
  72.         self.conf_info.define("tools.build:compiler_executables", {
  73.             "c":   f"{toolchain}-gcc",
  74.             "cpp": f"{toolchain}-g++",
  75.             "asm": f"{toolchain}-as"
  76.         })

Validating the toolchain package: settings, settings_build and settings_target

As you may recall, the validate() method is used to indicate that a package is not compatible with certain configurations. As mentioned earlier, we are limiting the usage of this package to a Linux x86_64 platform for cross-compiling to a Linux ARM target, supporting both 32-bit and 64-bit architectures. Let’s check how we incorporate this information into the validate() method and discuss the various types of settings involved:

Validating the build platform

  1. ...
  3. settings = "os", "arch"
  5. ...
  7. def validate(self):
  9.     if self.settings.arch != "x86_64" or self.settings.os != "Linux":
  10.         raise ConanInvalidConfiguration(f"This toolchain is not compatible with {self.settings.os}-{self.settings.arch}. "
  11.                                         "It can only run on Linux-x86_64.")
  12.     ...

First, it’s important to acknowledge that only the os and arch settings are declared. These settings represent the machine that will compile the package for the toolchain, so we only need to verify that they correspond to Linux and x86_64, as these are the platforms for which the toolchain binaries are intended.

It is important to note that for this package, which is to be used as a tool_requires, these settings do not relate to the host profile but to the build profile. This distinction is recognized by Conan when creating the package with the --build-require argument. This will make the settings and the settings_build to be equal within the context of package creation.

Validating the target platform

In scenarios involving cross-compilation, validations regarding the target platform, where the executable generated by the toolchain’s compilers will run, must refer to the settings_target. These settings come from the information in the host profile. For instance, if compiling for a Raspberry Pi, that will be the information stored in the settings_target. Again, Conan is aware that settings_target should be populated with the host profile information due to the use of the --build-require flag during package creation.

  1. def validate(self):
  2.     ...
  4.     valid_archs = self._archs32() + self._archs64()
  5.     if self.settings_target.os != "Linux" or self.settings_target.arch not in valid_archs:
  6.         raise ConanInvalidConfiguration(f"This toolchain only supports building for Linux-{valid_archs.join(',')}. "
  7.                                        f"{self.settings_target.os}-{self.settings_target.arch} is not supported.")
  9.     if self.settings_target.compiler != "gcc":
  10.         raise ConanInvalidConfiguration(f"The compiler is set to '{self.settings_target.compiler}', but this "
  11.                                         "toolchain only supports building with gcc.")
  13.     if Version(self.settings_target.compiler.version) >= Version("14") or Version(self.settings_target.compiler.version) < Version("13"):
  14.         raise ConanInvalidConfiguration(f"Invalid gcc version '{self.settings_target.compiler.version}'. "
  15.                                         "Only 13.X versions are supported for the compiler.")

As you can see, several verifications are made to ensure the validity of the operating system and architectures for the resulting binaries’ execution environment. Additionally, it verifies that the compiler’s name and version align with the expectations for the host context.

Here, the diagram shows both profiles and which settings are picked for the arm-toolchain recipe that is in the build context.

digraph context_diagram { subgraph cluster_build_context { label = “build context”; fontname = Helvetica; labeljust = “l”; style=filled; color=lightblue; “arm-toolchain/13.2” [shape=box, style=filled, color=lightblue, fontname=Helvetica] “settings” [shape=box, style=filled, fillcolor=lightblue, fontname=Helvetica] “settings_target” [shape=box, style=filled, fillcolor=pink, fontname=Helvetica] } subgraph cluster_build_profile { label=”build profile”; labeljust = “l”; fontname = Helvetica; color=white “build_profile” [shape=record, label=”[settings]\larch=x86_64\lbuild_type=Release\lcompiler=gcc\lcompiler.cppstd=gnu14\lcompiler.version=7\los=Linux\l”, style=filled, color=lightblue, fontname=Helvetica] } subgraph cluster_host_profile { label = “host profile”; labeljust = “l”; fontname = Helvetica color = white; “host_profile” [shape=record, label=”[settings]\larch=armv8\lbuild_type=Release\lcompiler=gcc\lcompiler.cppstd=gnu14\lcompiler.version=13\los=Linux\l”, style=filled, color=pink, fontname=Helvetica] } “build_profile” -> “settings” “host_profile” -> “settings_target” }

Downloading the binaries for the toolchain and packaging it

  1. ...
  3. def _archs32(self):
  4.     return ["armv6", "armv7", "armv7hf"]
  6. def _archs64(self):
  7.     return ["armv8", "armv8.3"]
  9. def _get_toolchain(self, target_arch):
  10.     if target_arch in self._archs32():
  11.         return ("arm-none-linux-gnueabihf",
  12.                 "df0f4927a67d1fd366ff81e40bd8c385a9324fbdde60437a512d106215f257b3")
  13.     else:
  14.         return ("aarch64-none-linux-gnu",
  15.                 "12fcdf13a7430655229b20438a49e8566e26551ba08759922cdaf4695b0d4e23")
  17. def source(self):
  18.     download(self, "https://developer.arm.com/GetEula?Id=37988a7c-c40e-4b78-9fd1-62c20b507aa8", "LICENSE", verify=False)
  20. def build(self):
  21.     toolchain, sha = self._get_toolchain(self.settings_target.arch)
  22.     get(self, f"https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-{toolchain}.tar.xz",
  23.         sha256=sha, strip_root=True)
  25. def package(self):
  26.     toolchain, _ = self._get_toolchain(self.settings_target.arch)
  27.     dirs_to_copy = [toolchain, "bin", "include", "lib", "libexec"]
  28.     for dir_name in dirs_to_copy:
  29.         copy(self, pattern=f"{dir_name}/*", src=self.build_folder, dst=self.package_folder, keep_path=True)
  30.     copy(self, "LICENSE", src=self.build_folder, dst=os.path.join(self.package_folder, "licenses"), keep_path=False)
  32. ...

The source() method is used to download the recipe license, as it’s found on the ARM toolchains’ download page. However, this is the only action performed there. The actual toolchain binaries are fetched in the build() method. This approach is necessary because the toolchain package is designed to support both 32-bit and 64-bit architectures, requiring us to download two distinct sets of toolchain binaries. Which binary the package ends up with depends on the settings_target architecture. This conditional downloading process can’t happen in the source() method, as it caches the downloaded contents.

The package() method doesn’t have anything out of the ordinary; it simply copies the downloaded files into the package folder, license included.

Adding settings_target to the Package ID information

In recipes designed for cross-compiling scenarios, particularly those involving toolchains that target specific architectures or operating systems, and the binary package can be different based on the target platform we may need to modify the package_id() to ensure that Conan correctly identifies and differentiates between binaries based on the target platform they are intended for.

In this case, we extend the package_id() method to include settings_target, which encapsulates the target platform’s configuration (in this case if it’s 32 or 64 bit):

  1. def package_id(self):
  2.     # Assign settings_target to the package ID to differentiate binaries by target platform.
  3.     self.info.settings_target = self.settings_target
  5.     # We only want the ``arch`` setting
  6.     self.info.settings_target.rm_safe("os")
  7.     self.info.settings_target.rm_safe("compiler")
  8.     self.info.settings_target.rm_safe("build_type")

By specifying self.info.settings_target = self.settings_target, we explicitly instruct Conan to consider the target platform’s settings when generating the package ID. In this case we remove os, compiler and build_type settings as changing them will not be relevant for selecting the toolchain we will use for building and leave only the arch setting that will be used to decide if want to produce binaries for 32 or 64 bits.

Define information for consumers

In the package_info() method we define all the information that consumers need to have available when using the toolchain:

  1. def package_info(self):
  2.     toolchain, _ = self._get_toolchain(self.settings_target.arch)
  3.     self.cpp_info.bindirs.append(os.path.join(self.package_folder, toolchain, "bin"))
  5.     self.conf_info.define("tools.build:compiler_executables", {
  6.         "c":   f"{toolchain}-gcc",
  7.         "cpp": f"{toolchain}-g++",
  8.         "asm": f"{toolchain}-as"
  9.     })

In this case, we need to define the following information:

  • Add directories containing toolchain tools that may be required during compilation. The toolchain we download will store its tools in both bin and <toolchain_triplet>/bin. Since self.cpp_info.bindirs defaults to bin, we only need to add the directory specific to the triplet. Note that it’s not necessary to define environment information to add these directories to the PATH, as Conan will manage this through the VirtualRunEnv.

  • We define the tools.build:compiler_executables configuration. This configuration will be considered in several generators, like CMakeToolchain, MesonToolchain, or AutotoolsToolchain, to direct to the appropriate compiler binaries.

Testing the Conan toolchain package

We also added a simple test_package to test the toolchain:

test_package/conanfile.py

  1. import os
  2. from io import StringIO
  4. from conan import ConanFile
  5. from conan.tools.cmake import CMake, cmake_layout
  8. class TestPackageConan(ConanFile):
  9.     settings = "os", "arch", "compiler", "build_type"
  10.     generators = "CMakeToolchain", "VirtualBuildEnv"
  12.     def build_requirements(self):
  13.         self.tool_requires(self.tested_reference_str)
  15.     def layout(self):
  16.         cmake_layout(self)
  18.     def build(self):
  19.         cmake = CMake(self)
  20.         cmake.configure()
  21.         cmake.build()
  23.     def test(self):
  24.         if self.settings.arch in ["armv6", "armv7", "armv7hf"]:
  25.             toolchain = "arm-none-linux-gnueabihf"
  26.         else:
  27.             toolchain = "aarch64-none-linux-gnu"
  28.         self.run(f"{toolchain}-gcc --version")
  29.         test_file = os.path.join(self.cpp.build.bindirs[0], "test_package")
  30.         stdout = StringIO()
  31.         self.run(f"file {test_file}", stdout=stdout)
  32.         if toolchain == "aarch64-none-linux-gnu":
  33.             assert "ELF 64-bit" in stdout.getvalue()
  34.         else:
  35.             assert "ELF 32-bit" in stdout.getvalue()

This test package ensures that the toolchain is functional, building a minimal hello world program and that binaries produced with it are correctly targeted for the specified architecture.

Cross-build an application using the toolchain

Having detailed the toolchain recipe, it’s time to proceed with package creation:

  1. $ conan create . -pr:b=default -pr:h=../profiles/raspberry-64 --build-require
  3. ======== Exporting recipe to the cache ========
  4. ...
  5. ======== Input profiles ========
  6. Profile host:
  7. [settings]
  8. arch=armv8
  9. build_type=Release
  10. compiler=gcc
  11. compiler.cppstd=gnu14
  12. compiler.libcxx=libstdc++11
  13. compiler.version=13
  14. os=Linux
  16. Profile build:
  17. [settings]
  18. arch=x86_64
  19. build_type=Release
  20. compiler=gcc
  21. compiler.cppstd=gnu14
  22. compiler.libcxx=libstdc++11
  23. compiler.version=7
  24. os=Linux
  25. ...
  26. ======== Testing the package: Executing test ========
  27. arm-toolchain/13.2 (test package): Running test()
  28. arm-toolchain/13.2 (test package): RUN: aarch64-none-linux-gnu-gcc --version
  29. aarch64-none-linux-gnu-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009
  30. Copyright (C) 2023 Free Software Foundation, Inc.
  31. ...

We employ two profiles for the build and host contexts, but the most important detail is the use of the –build-require argument. This informs Conan that the package is intended as a build requirement, situating it within the build context. Consequently, settings match those from the build profile, while settings_target aligns with the host profile’s settings.

With the toolchain package prepared, we proceed to build an actual application. This will be the same application previously cross-compiled in the How to cross-compile your applications using Conan: host and build contexts section. However, this time, we incorporate the toolchain package as a dependency within the host profile. This ensures the toolchain is used to build the application and all its dependencies

  1. $ cd .. && cd consumer
  2. $ conan install . -pr:b=default -pr:h=../profiles/raspberry-64 -pr:h=../profiles/arm-toolchain --build missing
  3. $ cmake --preset conan-release
  4. $ cmake --build --preset conan-release
  5. $ file ./build/Release/compressor
  6. compressor: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically
  7. linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, with debug_info,
  8. not stripped

We composed the already existing profile with another profile called arm-toolchain that just has the tool_requires added:

  1. [tool_requires]
  2. arm-toolchain/13.2

During this procedure, the zlib dependency will also be compiled for ARM 64-bit architecture if it hasn’t already been. Additionally, it’s important to verify the architecture of the resulting executable, confirming its alignment with the targeted 64-bit architecture.

See also