Buildroot is a tool that I’ve already covered in a previous blog post. To me, its main purpose is to build the root filesystem for an embedded Linux system, with all the necessary applications and libraries. It automates the tedious process of cross-compiling and integrating all the free software components in an embedded system.
In addition to root filesystem generation, Buildroot is also known for its ability to generate a uClibc-based cross-compilation toolchain. Buildroot used to be for quite some time the only way to generate a toolchain based on this size-effective C library, but it is no longer the case with Crosstool-NG supporting glibc, uClibc and eglibc.
However, I’ve personaly never been really satisfied with uClibc generation of cross-compiling toolchains:
- It mixes the process of the cross-compilingn toolchain generation with the process of root filesystem generation, which are, in my opinion, two very different processes. Once your toolchain is generated, you generally don’t touch it, but regenerate your root filesystem dozens or hundred of times until all your components are here and properly integrated.
- The attention paid to toolchain generation in the Buildroot project itself is relatively small, while other projects like Crosstool-NG or vendors like Codesourcery, are specifically dedicated to providing toolchains. The fact that, for example, uClibc is the only C library supported is one example of this.
- It might necessary, for various reasons, make sense to use an already existing toolchain.
Support for the usage of external toolchains has already been present in Buildroot for a long time, but wasn’t developed enough to be easily usable. Months ago, I’ve started to improve the situation (here, here, here and here), and last week, two other patches have been integrated.
- The first patch, visible here removes the ugly configuration option that allows to configure the set of libraries that must be copied to the target filesystem, and replaces it with a nice selection of the C libary type: uClibc or glibc. It makes it clear that generating Linux system with the glibc library is possible with Buildroot, even if Buildroot has often been advertised as a uClibc only tool.
- The second patch, visible here adds checks for the conformity of Buildroot configuration versus the C library configuration. There are configuration options in Buildroot that must tell whether the C library supports IPv6, supports RPC, supports locale, supports large file, etc. These options must be set in the configuration interface according to the C library configuration, because some userspace packages depend on them. The added checks verify that the value set to these options match the configuration of your C library
So, now, external toolchains are a little bit easier to use with Buildroot, and your own vendor toolchain, Codesourcery toolchains or any other toolchain can be used with Buildroot. The only requirement is that the toolchain supports the sysroot feature, which is very common in most toolchains.
Hi Sir:
I want to use the external toolchain,but I always got the error message “Incorrect select C library”.
I use the git to get lastly source code,did I need to do the patch??
Hi,
Comment forms on this website are not meant to be used to get technical support. See the Buildroot mailing lists instead: http://lists.busybox.net/mailman/listinfo/buildroot
Good luck,
Michael.
Posting a comment for Joel Ding…
“Incorrect selection of C library” may come from the misplacement of
your toolchain. Whether a toolchain could be placed anywhere you want
or a fixed directory depends on how it was generated.
I met exactly the same question as Juncor with a cross-toolchain released
by Bootlin. However, after I moved the xtools directory to /usr/local,
everything appeared normally. I have successfully used latest Buildroot
(2010.02) to build an ext2 image.
To guys of this website,
The material presented in this website is fabulous. I believe many
engineers worldwide are reading your blogs. Hopefully someday you will
host speech in Taiwan.
Warm regards,
Joel Ding