Compile kernel and userspace with two different toolchains in buildroot

653 views Asked by At

Working with an old ARM board running a 2.6.35-custom kernel. Manufacturer provides two different cross-toolchains:

* gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) --> kernel toolchain
* gcc version 4.9.4 (crosstool-NG crosstool-ng-1.23.0) --> userspace toolchain

Manufacturer also provides a set of scripts acting as glue to compile kernel, modules, and make a package of the final rootfs.

My purpose is removing all custom "glue" scripts, and integrating the whole build process in a single buildroot. I have chosen buildroot-2016.08.01.

Running the buildroot menuconfig and setting this variables:

BR2_TOOLCHAIN_EXTERNAL_PATH="/opt/arm/crosstool-ng/"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="armv5te-linux-gnueabi"
BR2_TOOLCHAIN_EXTERNAL_PREFIX="armv5te-linux-gnueabi"

I can set the external userspace toolchain. The userspace compilation works fine, generating a final rootfs as expected.

And here my question: is it possible to define two external toolchains in buildroot, one to compile the kernel and other one to compile the rootfs userspace? I am not sure. I haven't found anything related in buildroot documentation.

I think buildroot is expecting the same toolchain to compile both kernel and userspace. But I have issues when trying to use just a single toolchain for compiling both of them.

a) if I try to compile userspace with kernel toolchain, it fails compiling busybox:

debianutils/lib.a(mktemp.o): In function `mktemp_main':
mktemp.c:(.text.mktemp_main+0x98): warning: the use of `mktemp' is dangerous, better use `mkstemp'
util-linux/lib.a(nsenter.o): In function `nsenter_main':
nsenter.c:(.text.nsenter_main+0x180): undefined reference to `setns'
coreutils/lib.a(sync.o): In function `sync_main':
sync.c:(.text.sync_main+0x78): undefined reference to `syncfs'
collect2: ld returned 1 exit status
Note: if build needs additional libraries, put them in CONFIG_EXTRA_LDLIBS.
Example: CONFIG_EXTRA_LDLIBS="pthread dl tirpc audit pam"
make[1]: *** [busybox_unstripped] Error 1
make[1]: Leaving directory `/usr/local/buildroot/output/build/busybox-1.25.0'

b) if I try to compile the kernel with userspace toolchain, I get unexpected errors:

In file included from /linux-2.6.35-custom/arch/arm/include/asm/page.h:206:0,
                 from include/linux/mmzone.h:20,
                 from include/linux/gfp.h:4,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from arch/arm/okl4-microvisor/vmmu.c:14:
arch/arm/okl4-microvisor/vmmu.c: In function 'reserve_node_zero':
arch/arm/okl4-microvisor/vmmu.c:488:35: error: taking address of expression of type 'void' [-Werror]
  reserve_bootmem_node(pgdat, __pa(&_stext), &_end - &_stext,
                               ^
/linux-2.6.35-custom/arch/arm/include/asm/memory.h:150:29: note: in definition of macro '__virt_to_phys'
 #define __virt_to_phys(x) ((x) - PAGE_OFFSET + PHYS_OFFSET)
                         ^
arch/arm/okl4-microvisor/vmmu.c:488:30: note: in expansion of macro '__pa'
  reserve_bootmem_node(pgdat, __pa(&_stext), &_end - &_stext,
                          ^
arch/arm/okl4-microvisor/vmmu.c:488:45: error: taking address of expression of type 'void' [-Werror]
  reserve_bootmem_node(pgdat, __pa(&_stext), &_end - &_stext,
                                         ^
arch/arm/okl4-microvisor/vmmu.c:488:53: error: taking address of expression of type 'void' [-Werror]
  reserve_bootmem_node(pgdat, __pa(&_stext), &_end - &_stext,
                                                 ^
arch/arm/okl4-microvisor/vmmu.c: In function 'setup_mm_for_reboot':
arch/arm/okl4-microvisor/vmmu.c:904:9: error: variable 'pgd' set but not used [-Werror=unused-but-set-variable]
  pgd_t *pgd;
         ^
cc1: all warnings being treated as errors
make[1]: *** [arch/arm/okl4-microvisor/vmmu.o] Error 1

However, everything works fine when compiling userspace and kernel with the proper toolchain. I don't undestand why this toolchain that works fine with userspace generates errors when compiling the kernel. Is this normal? Thank in advance!

0

There are 0 answers