[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[MikeW]

gcc-3.4.3
binutils-2.16.91.0.7
buildroot-20061031

Target Architecture: arm
Target Architecture Variant: arm926t
Target ABI: EABI
Build Options: GNU Target Suffix: ????
Toolchain options: Kernel Headers 2.6.11

Is there a way of building an EABI ARM toolchain using Buildroot ?
Or is it one of those things that is not currently possible ?

If I set the target suffix to 'elf-linux' the toolchain build
completes, but objects created with it have EABI version=0 (= no EABI).
(These will not link with a 3rd-party-built library with EABI version=4.)

If I set to to 'armelf-linux-eabi' or one of the other likely-
looking values, I get a build error from ld: 
 in/ld: unrecognised emulation mode: armelf_linux
 Supported emulations: armelf_linux_eabi

I can't see any other likely setting to change ...

Any ideas ?
Or do a need a newer version of Buildroot ... or a patch ?

Thanks,
MikeW

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[Pavel Roskin]

Hello!

On Wed, 2006-11-29 at 13:25 +0000, MikeW wrote:

> If I set the target suffix to 'elf-linux' the toolchain build
> completes, but objects created with it have EABI version=0 (= no EABI).
> (These will not link with a 3rd-party-built library with EABI version=4.)

How do you check that?

> If I set to to 'armelf-linux-eabi' or one of the other likely-
> looking values, I get a build error from ld: 
>  in/ld: unrecognised emulation mode: armelf_linux
>  Supported emulations: armelf_linux_eabi

You don't need the CPU part in the target, only the OS and the kernel
part.  In other word, you need something like "linux", "linux-gnu",
"linux-uclibc" etc.

> I can't see any other likely setting to change ...
> 
> Any ideas ?
> Or do a need a newer version of Buildroot ... or a patch ?

Remove BR2_GNU_TARGET_SUFFIX from .config and run "make oldconfig".  The
suggested value will be "linux-uclibcgnueabi" and it should work.

To make sure the suffix would work, run recent config.sub with the
arm-unknown-SUFFIX argument and make sure it's accepted.  Sometimes
config.sub can become confused if it doesn't know how to insert "gnu"
after "linux" :)

I still see it failing with gcc 3.4.6 and binutils 2.17.50.0.7:

/usr/local/src/buildroot/toolchain_build_arm/gcc-3.4.6-initial/gcc/xgcc
-B/usr/local/src/buildroot/toolchain_build_arm/gcc-3.4.6-initial/gcc/
-B/usr/local/src/buildroot/build_arm/staging_dir/arm-linux-uclibcgnueabi/bin/ -B/usr/local/src/buildroot/build_arm/staging_dir/arm-linux-uclibcgnueabi/lib/ -isystem /usr/local/src/buildroot/build_arm/staging_dir/arm-linux-uclibcgnueabi/include -isystem /usr/local/src/buildroot/build_arm/staging_dir/arm-linux-uclibcgnueabi/sys-include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fomit-frame-pointer -fPIC -g0  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I/usr/local/src/buildroot/toolchain_build_arm/gcc-3.4.6/gcc -I/usr/local/src/buildroot/toolchain_build_arm/gcc-3.4.6/gcc/. -I/usr/local/src/buildroot/toolchain_build_arm/gcc-3.4.6/gcc/../include   -DL_floatdisf -c /usr/local/src/buildroot/toolchain_build_arm/gcc-3.4.6/gcc/libgcc2.c -o libgcc/./_floatdisf.o
/tmp/cciYVnPk.s: Assembler messages:
/tmp/cciYVnPk.s:23: Error: selected processor does not support `ldfd f0,.L8+16'
/tmp/cciYVnPk.s:43: Error: selected processor does not support `fltd f1,r7'
/tmp/cciYVnPk.s:45: Error: selected processor does not support `mufd f1,f1,f0'
/tmp/cciYVnPk.s:46: Error: selected processor does not support `mufd f1,f1,f0'
/tmp/cciYVnPk.s:47: Error: selected processor does not support `fltd f2,r5'
/tmp/cciYVnPk.s:48: Error: selected processor does not support `ldfltd f0,.L8+32'
/tmp/cciYVnPk.s:49: Error: selected processor does not support `adfltd f2,f2,f0'
/tmp/cciYVnPk.s:50: Error: selected processor does not support `adfd f1,f1,f2'
/tmp/cciYVnPk.s:52: Error: selected processor does not support `mvfs f0,f1'
make[3]: *** [libgcc/./_floatdisf.o] Error 1

Maybe you can fix it.  You can try another compiler.

If I understand it correctly, the binutils and gcc configuration is
affected solely by BR2_GNU_TARGET_SUFFIX, not by BR2_ARM_EABI and
BR2_ARM_OABI values.  That's why it's important to get
BR2_GNU_TARGET_SUFFIX right.

-- 
Regards,
Pavel Roskin

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ? +

[MikeW]

MikeW <mw_phil@...> writes:

> 
> gcc-3.4.3
> binutils-2.16.91.0.7
> buildroot-20061031
> 
> Target Architecture: arm
> Target Architecture Variant: arm926t
> Target ABI: EABI
> Build Options: GNU Target Suffix: ????
> Toolchain options: Kernel Headers 2.6.11

Also: need to select software FP:

Toolchain Options: Use software floating point by default

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[MikeW]

Pavel Roskin <proski@...> writes:
>
> Hello!
>
> On Wed, 2006-11-29 at 13:25 +0000, MikeW wrote:
>
> > If I set the target suffix to 'elf-linux' the toolchain build
> > completes, but objects created with it have EABI version=0 (= no EABI).
> > (These will not link with a 3rd-party-built library with EABI version=4.)
>
> How do you check that?

objdump -x objectfile.o

> 
> You don't need the CPU part in the target, only the OS and the kernel
> part.  In other word, you need something like "linux", "linux-gnu",
> "linux-uclibc" etc.

I *do* miss out the CPU part in the menuconfig option field.
I have also tried using the default setting for the field,
which is linux-uclibcgnueabi, as you suggest.

>
> > I can't see any other likely setting to change ...
> > 
> > Any ideas ?
> > Or do a need a newer version of Buildroot ... or a patch ?
>
> Remove BR2_GNU_TARGET_SUFFIX from .config and run "make oldconfig".  The
> suggested value will be "linux-uclibcgnueabi" and it should work.
>
> To make sure the suffix would work, run recent config.sub with the
> arm-unknown-SUFFIX argument and make sure it's accepted.  Sometimes
> config.sub can become confused if it doesn't know how to insert "gnu"
> after "linux" :)
>
> I still see it failing with gcc 3.4.6 and binutils 2.17.50.0.7:
>

[As per my other post] You also need to specify software FP.

> 
> Maybe you can fix it.  You can try another compiler.
> 

It appears that (most of) the toolchain *is* built correctly.
The relevant directory in staging_dir/bin contains files like
arm-linux-uclibcgnueabi-gcc - correct !

If I build an object file with this compiler after the aborted
Buildroot make, it has EABI version=4, as required.

The problem seems to be with the step in building the gcc package
which checks for 'supported emulations' using ld.

Something seems to cause a mismatch between what is seen,
and what is expected - this looks like a gcc/ld problem, at least
with the configuration that Buildroot gives to it.

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[Pavel Roskin]

On Thu, 2006-11-30 at 11:14 +0000, MikeW wrote:
> This seems to be due to an incompatibility between:
> 1) toolchain.../gcc-x.x.x/config/arm/linux-elf.h
> 2) toolchain.../binutils-x.x.x/ld/earmelf_linux_eabi.c
> 
> In 1) there is a setting TARGET_LINKER_EMULATION "armelf_linux"
> In 2) there is a string (part of a struct initialiser) "armelf_linux_eabi"
> 
> so unless I can find matching strings in a version of gcc and ld,
> buildroot will never be able to build a toolchain.

There are already patches for gcc in buildroot that change
TARGET_LINKER_EMULATION for bigendian systems and uClibc.  I think
support for EABI belongs there too.

-- 
Regards,
Pavel Roskin

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[MikeW]

Pavel Roskin <proski@...> writes:


> There are already patches for gcc in buildroot that change
> TARGET_LINKER_EMULATION for bigendian systems and uClibc.  I think
> support for EABI belongs there too.
> 

So looking at 800-arm-bigendian.patch, it would appear
that I need to
1) in config.gcc, have a case $target that detects
 *eabi and sets a TARGET_EABI flag
2) in linux-elf.h, have another #if TARGET_EABI ... #else ... #endif
 which just tags "_eabi" onto all of the other strings, if EABI is active

Does this make sense ?

Or is there an official GCC patch to do this (I have searched!)

Since other people are building ARM EABI versions of gcc, there must
be a patch that they are using which somehow has been omitted
from Buildroot :(

Regards,
Mike

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[MikeW]

MikeW <mw_phil@...> writes:

> Since other people are building ARM EABI versions of gcc, there must
> be a patch that they are using which somehow has been omitted
> from Buildroot :(
> 
> Regards,
> Mike
> 

Incidentally, why don't projects using gcc just inherit all their
patches from gcc ... it seems (from searching) as if each dependent
project has to reinvent its own patches each time, whereas once a fix is found,
it should just go to gcc for everyone to use once & for all, thereby saving
everyone a lot of time and effort.

This should be part of the 'synergy' of open source ...
;-)

Regards,
MikeW

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[MikeW]

Pavel Roskin <proski@...> writes:
> There are already patches for gcc in buildroot that change
> TARGET_LINKER_EMULATION for bigendian systems and uClibc.  I think
> support for EABI belongs there too.
> 

So how do we get these included into Buildroot ?
There are patches for EABI working mentioned on gcc.gnu.org dating back to 2004.
But no systematic list anywhere (?), or information about applying them.
We need the wheel to be invented *once* !!
;-)

Thanks again,
MikeW

[Buildroot] Impossible to build EABI ARM gcc toolchain?using?Buildroot ?

[Bernhard Fischer]

On Wed, Dec 13, 2006 at 12:08:41PM +0000, MikeW wrote:
>Pavel Roskin <proski@...> writes:
>> There are already patches for gcc in buildroot that change
>> TARGET_LINKER_EMULATION for bigendian systems and uClibc.  I think
>> support for EABI belongs there too.
>> 
>
>So how do we get these included into Buildroot ?

Someone who knows arm writes, tests and applies them. I don't do
arm (don't have a board and don't intend to play with an emulated
one, fwiw), sorry.

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[MikeW]

Pavel Roskin <proski@...> writes:

> Maybe you can fix it.  You can try another compiler.

Unfortunately, Buldroot gcc-4.1.1 which includes ARM EABI support won't build
the 2.6.10 kernel we are using - fails in the get_user macro in uaccess.h.

Patch that, something else breaks in a similar way due to the compiler
breaking code that worked under gcc-3.4.x (it needs a switch to turn this off!)

The joys of bazaar development - grrr !

Regards,
MikeW

[Buildroot] Impossible to build EABI ARM gcc toolchain using Buildroot ?

[MikeW]

MikeW <mw_phil@...> writes:

> 
> Pavel Roskin <proski <at> ...> writes:
> 
> > Maybe you can fix it.  You can try another compiler.
> 
> Unfortunately, Buldroot gcc-4.1.1 which includes ARM EABI support won't build
> the 2.6.10 kernel we are using - fails in the get_user macro in uaccess.h.
> 
> Patch that, something else breaks in a similar way due to the compiler
> breaking code that worked under gcc-3.4.x (it needs a switch to turn this off!)
> 
> The joys of bazaar development - grrr !
> 
> Regards,
> MikeW
> 

Looks like the only 3.4.x version of GCC is the one from CodeSourcery,
http://www.codesourcery.com/gnu_toolchains/arm/releases.html
I think one of the older ones is derived from a 3.4.x GCC.

Was considering doing a Buildroot config.in patch to get the tar.bz2 file from
the CS website, but unfortunately the files are returned in response
to a form submission :(

MikeW

[Buildroot] Impossible to build EABI ARM gcc toolchain?using?Buildroot ?

[Bernhard Fischer]

On Mon, Dec 18, 2006 at 11:37:11AM +0000, MikeW wrote:
>MikeW <mw_phil@...> writes:
>
>> 
>> Pavel Roskin <proski <at> ...> writes:
>> 
>> > Maybe you can fix it.  You can try another compiler.
>> 
>> Unfortunately, Buldroot gcc-4.1.1 which includes ARM EABI support won't build
>> the 2.6.10 kernel we are using - fails in the get_user macro in uaccess.h.
>> 
>> Patch that, something else breaks in a similar way due to the compiler
>> breaking code that worked under gcc-3.4.x (it needs a switch to turn this off!)
>> 
>> The joys of bazaar development - grrr !
>> 
>> Regards,
>> MikeW
>> 
>
>Looks like the only 3.4.x version of GCC is the one from CodeSourcery,
>http://www.codesourcery.com/gnu_toolchains/arm/releases.html
>I think one of the older ones is derived from a 3.4.x GCC.
>
>Was considering doing a Buildroot config.in patch to get the tar.bz2 file from
>the CS website, but unfortunately the files are returned in response
>to a form submission :(

huh?
http://www.codesourcery.com/public/gnu_toolchain/$target/arm-2006q3-27-$target.src.tar.bz2

for e.g. target=arm-none-eabi

I don't see the problem, really..

Apart from that, it's beyond me why would one want/need to use 2.6.10