[Buildroot] [PATCH] sh4: fix toolchain creation

[Buildroot] [PATCH] sh4: fix toolchain creation

[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.

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 <wbx@openadk.org>
---
 configs/qemu_sh4_r2d_defconfig     |    4 ----
 package/gcc/gcc-final/gcc-final.mk |    6 ++++++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/configs/qemu_sh4_r2d_defconfig b/configs/qemu_sh4_r2d_defconfig
index 88bf914..586c400 100644
--- a/configs/qemu_sh4_r2d_defconfig
+++ b/configs/qemu_sh4_r2d_defconfig
@@ -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"
diff --git a/package/gcc/gcc-final/gcc-final.mk b/package/gcc/gcc-final/gcc-final.mk
index c014bc5..607e850 100644
--- a/package/gcc/gcc-final/gcc-final.mk
+++ b/package/gcc/gcc-final/gcc-final.mk
@@ -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
-- 
1.7.10.4

[Buildroot] [PATCH] sh4: fix toolchain creation

[Arnout Vandecappelle]

 Hi Waldemar,

On 20/03/15 19:22, Waldemar Brodkorb wrote:
> 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...


> 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:

> 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?


 Regards,
 Arnout


> 
> 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 <wbx@openadk.org>
> ---
>  configs/qemu_sh4_r2d_defconfig     |    4 ----
>  package/gcc/gcc-final/gcc-final.mk |    6 ++++++
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/configs/qemu_sh4_r2d_defconfig b/configs/qemu_sh4_r2d_defconfig
> index 88bf914..586c400 100644
> --- a/configs/qemu_sh4_r2d_defconfig
> +++ b/configs/qemu_sh4_r2d_defconfig
> @@ -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"
> diff --git a/package/gcc/gcc-final/gcc-final.mk b/package/gcc/gcc-final/gcc-final.mk
> index c014bc5..607e850 100644
> --- a/package/gcc/gcc-final/gcc-final.mk
> +++ b/package/gcc/gcc-final/gcc-final.mk
> @@ -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
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] sh4: fix toolchain creation

[Waldemar Brodkorb]

Hi Arnout,
Arnout Vandecappelle wrote,

>  Hi Waldemar,
> 
> On 20/03/15 19:22, Waldemar Brodkorb wrote:
> > 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...

Thomas wants to update the external toolchain for sh4, but build
fails.
 
> > 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:
> 
> > 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.

Yes. No regression so far :)
 
>  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?

Producing a sh4 toolchain with buidroot works after this patch,
which did not work before.
I made a short test of a static linked bash produced by this
toolchain on my SNAPGear SME575:
/tmp/bash --version
GNU bash, version 4.3.33(1)-release (sh4-buildroot-linux-uclibc)
# uname -a
Linux SG575 2.4.31-uc0 #1 Thu Feb 7 21:35:20 EST 2008 sh4 unknown
# cat /proc/cpuinfo 
cpu family      : SH-4
cache size      : 8K-byte/16K-byte
bogomips        : 239.20

Machine: SnapGear
CPU clock: 239.98MHz
Bus clock: 119.99MHz
Peripheral module clock: 119.99MHz

Looks okay. Still need to get a newer kernel and libc on the box:
uClibc 0.9.27 preinstalled ;)

best regards
 Waldemar 

[Buildroot] [PATCH] sh4: fix toolchain creation

[Arnout Vandecappelle]

On 21/03/15 23:52, Waldemar Brodkorb wrote:
> I made a short test of a static linked bash produced by this
> toolchain on my SNAPGear SME575:

 That's what I meant!

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] sh4: fix toolchain creation

[Thomas Petazzoni]

Dear Waldemar Brodkorb,

On Fri, 20 Mar 2015 19:22:15 +0100, Waldemar Brodkorb wrote:
> 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 <wbx@openadk.org>

It still doesn't build here. Maybe it worked for you because you did
not enable C++ support. Here is the defconfig I test:

BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="se7724"

It fails as follows:

(cd /home/test/outputs/sh4/host/usr/bin; for i in sh4-buildroot-linux-uclibc-*; do ln -snf $i sh4-linux${i##sh4-buildroot-linux-uclibc}; done)
cp -dpf /home/test/outputs/sh4/host/usr/sh4-buildroot-linux-uclibc/lib*/libgcc_s* /home/test/outputs/sh4/host/usr/sh4-buildroot-linux-uclibc/sysroot/lib/
cp: cannot stat `/home/test/outputs/sh4/host/usr/sh4-buildroot-linux-uclibc/lib*/libgcc_s*': No such file or directory
make[1]: [/home/test/outputs/sh4/build/host-gcc-final-4.8.4/.stamp_host_installed] Error 1 (ignored)
cp -dpf /home/test/outputs/sh4/host/usr/sh4-buildroot-linux-uclibc/lib*/libgcc_s* /home/test/outputs/sh4/target/lib/
cp: cannot stat `/home/test/outputs/sh4/host/usr/sh4-buildroot-linux-uclibc/lib*/libgcc_s*': No such file or directory
make[1]: [/home/test/outputs/sh4/build/host-gcc-final-4.8.4/.stamp_host_installed] Error 1 (ignored)
mkdir -p /home/test/outputs/sh4/target/usr/lib
for i in  libstdc++ ; do cp -dpf /home/test/outputs/sh4/host/usr/sh4-buildroot-linux-uclibc/lib*/${i}.a /home/test/outputs/sh4/host/usr/sh4-buildroot-linux-uclibc/sysroot/usr/lib/ ; done
cp: cannot stat `/home/test/outputs/sh4/host/usr/sh4-buildroot-linux-uclibc/lib*/libstdc++.a': No such file or directory
make[1]: *** [/home/test/outputs/sh4/build/host-gcc-final-4.8.4/.stamp_host_installed] Error 1
make: *** [_all] Error 2

Also, what about sh4a and sh4aeb ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com