sh4: fix toolchain creation

The Linux kernel does force compile with -m4-nofpu, which is only available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for gcc configure, but enables --with-multilib-list=m4,m4-nofpu in the default configuration for Qemu targeting r2d emulation. This results in a toolchain, which can be used for the kernel and for userland without creating a multilib toolchain with different kinds of libgcc version. In the multilib case there would be some subdirectories created like !m4 or m4-nofpu. As buildroot uses a short version of toolchain creation, a multilib enabled gcc build fails when creating libgcc.

So the best solution is to just keep multilib disabled, but always add --with-multilib-list=m4,m4-nofpu when sh4/sh4eb is choosen.

Tested with sh4 minimal toolchain build and qemu defconfig with gcc 4.8.x and uClibc.

To sum up, compiling gcc with disabled multilib, but with a mulitlib-list provides a working toolchain which can create sh4 nofpu code without trying to create a libgcc for every variant.

Signed-off-by Waldemar Brodkorb <[email protected]>

---
 configs/qemu_sh4_r2d_defconfig     |    4 ----
 package/gcc/gcc-final/gcc-final.mk |    6 ++++++
 2 files changed, 6 insertions(+), 4 deletions(-)

configs/qemu_sh4_r2d_defconfig +0 -4

index 88bf914..586c400 100644
@@ -10,10 +10,6 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttySC1"
 BR2_TARGET_ROOTFS_EXT2=y
 # BR2_TARGET_ROOTFS_TAR is not set
 
-# The kernel wants to use the -m4-nofpu option to make sure that it
-# doesn't use floating point operations.
-BR2_EXTRA_GCC_CONFIG_OPTIONS="--with-multilib-list=m4,m4-nofpu"
-
 # Lock to 3.19 headers to avoid breaking with newer kernels
 BR2_KERNEL_HEADERS_VERSION=y
 BR2_DEFAULT_KERNEL_VERSION="3.19"

package/gcc/gcc-final/gcc-final.mk +6 -0

index c014bc5..607e850 100644
@@ -53,6 +53,12 @@ HOST_GCC_FINAL_CONF_OPTS = \
 	--enable-poison-system-directories \
 	--with-build-time-tools=$(HOST_DIR)/usr/$(GNU_TARGET_NAME)/bin
 
+# The kernel wants to use the -m4-nofpu option to make sure that it
+# doesn't use floating point operations.
+ifeq ($(BR2_sh4)$(BR2_sh4eb),y)
+HOST_GCC_FINAL_CONF_OPTS += "--with-multilib-list=m4,m4-nofpu"
+endif
+
 # Disable shared libs like libstdc++ if we do static since it confuses linking
 ifeq ($(BR2_STATIC_LIBS),y)
 HOST_GCC_FINAL_CONF_OPTS += --disable-shared

Hi Waldemar,

Quoted 11 lines · Waldemar Brodkorb

The Linux kernel does force compile with -m4-nofpu, which is only available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for gcc configure, but enables --with-multilib-list=m4,m4-nofpu in the default configuration for Qemu targeting r2d emulation. This results in a toolchain, which can be used for the kernel and for userland without creating a multilib toolchain with different kinds of libgcc version. In the multilib case there would be some subdirectories created like !m4 or m4-nofpu. As buildroot uses a short version of toolchain creation, a multilib enabled gcc build fails when creating libgcc.

To be honest, I still don't understand what's going on here despite all this
explanation...

Quoted 2 lines

So the best solution is to just keep multilib disabled, but always add --with-multilib-list=m4,m4-nofpu when sh4/sh4eb is choosen.

But this sounds sane.

However:

Quoted 2 lines

Tested with sh4 minimal toolchain build and qemu defconfig with gcc 4.8.x and uClibc.

If I understand correctly, you applied your patch and tested that
qemu_sh4_r2d_defconfig still works, right? Well, that should come as no surprise since it just moves the --with-multilib-list option from one place to the other, so you'll end up with exactly the same toolchain.

The real question is: does it also work for other SH targets? Does it work on
real hardware? Or rather, is there anything that used to work that breaks now?

I made a short test of a static linked bash produced by this toolchain on my SNAPGear SME575:

The Linux kernel does force compile with -m4-nofpu, which is only available when building a multilib toolchain.
The interesting part here is, that buildroot use --disable-multilib for gcc configure, but enables --with-multilib-list=m4,m4-nofpu in the default configuration for Qemu targeting r2d emulation. This results in a toolchain, which can be used for the kernel and for userland without creating a multilib toolchain with different kinds of libgcc version. In the multilib case there would be some subdirectories created like !m4 or m4-nofpu. As buildroot uses a short version of toolchain creation, a multilib enabled gcc build fails when creating libgcc.

So the best solution is to just keep multilib disabled, but always add --with-multilib-list=m4,m4-nofpu when sh4/sh4eb is choosen.

Tested with sh4 minimal toolchain build and qemu defconfig with gcc 4.8.x and uClibc.

To sum up, compiling gcc with disabled multilib, but with a mulitlib-list provides a working toolchain which can create sh4 nofpu code without trying to create a libgcc for every variant.

Signed-off-by Waldemar Brodkorb <[email protected]>