[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Hamish Moffatt]

I'm trying to build the current buildroot for armeb/xscale with the
default settings (including gcc-4.2.1, uClibc 0.9.29) plus EABI.

The build fails trying to link libgcc_s.so during gcc-4.2.1-final:

/home/hamish/tmp/br/buildroot/toolchain_build_armeb/gcc-4.2.1-final/./gcc/xgcc -B/home/hamish/tmp/br/buildroot/toolchain_build_armeb/gcc-4.2.1-final/./gcc/ -B/usr/armeb-linux-uclibcgnueabi/bin/ -B/usr/armeb-linux-uclibcgnueabi/lib/ -isystem /usr/armeb-linux-uclibcgnueabi/include -isystem /usr/armeb-linux-uclibcgnueabi/sys-include -O2  -g -Os -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp  libgcc/./_udivsi3_s.o libgcc/./_divsi3_s.o libgcc/./_umodsi3_s.o libgcc/./_modsi3_s.o libgcc/./_bb_init_func_s.o libgcc/./_call_via_rX_s.o libgcc/./_interwork_call_via_rX_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_negdf2_s.o libgcc/./_addsubdf3_s.o libgcc/./_muldivdf3_s.o libgcc/./_cmpdf2_s.o libgcc/./_unorddf2_s.o libgcc/./_fixdfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_truncdfsf2_s.o libgcc/./_negsf2_s.o libgcc/./_addsubsf3_s.o libgcc/./_muldivsf3_s.o libgcc/./_cmpsf2_s.o libgcc/./_unordsf2_s.o libgcc/./_fixsfsi_s.o libgcc/./_fixunssfsi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundidf_s.o libgcc/./_floatundisf_s.o libgcc/./_aeabi_lcmp_s.o libgcc/./_aeabi_ulcmp_s.o libgcc/./_aeabi_ldivmod_s.o libgcc/./_aeabi_uldivmod_s.o libgcc/./_dvmd_lnx_s.o libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./bpabi_s.o libgcc/./unaligned-funcs_s.o libgcc/./unwind-arm_s.o libgcc/./libunwind_s.o libgcc/./pr-support_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
/home/hamish/tmp/br/buildroot/build_armeb/staging_dir/lib/libc.so.0: could not read symbols: File in wrong format

objdump shows that the files look correct and there's not a single little-endian .o 
in the tree so I'm a bit stumped.

Comparing libc.so.0 with a random object out of the above list it seems the flags are identical.
objdump -p says:

/home/hamish/tmp/br/buildroot/build_armeb/staging_dir/lib/libc.so.0:     file format elf32-bigarm

Program Header:
0x70000001 off    0x00038858 vaddr 0x00038858 paddr 0x00038858 align 2**2
         filesz 0x00000020 memsz 0x00000020 flags r--
    PHDR off    0x00000034 vaddr 0x00000034 paddr 0x00000034 align 2**2
         filesz 0x000000e0 memsz 0x000000e0 flags r-x
  INTERP off    0x00038828 vaddr 0x00038828 paddr 0x00038828 align 2**3
         filesz 0x00000018 memsz 0x00000018 flags r--
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00038878 memsz 0x00038878 flags r-x
    LOAD off    0x00038cd0 vaddr 0x00040cd0 paddr 0x00040cd0 align 2**15
         filesz 0x00000690 memsz 0x0000484c flags rw-
 DYNAMIC off    0x00038dc4 vaddr 0x00040dc4 paddr 0x00040dc4 align 2**2
         filesz 0x000000b8 memsz 0x000000b8 flags rw-
   RELRO off    0x00038cd0 vaddr 0x00040cd0 paddr 0x00040cd0 align 2**0
         filesz 0x00000330 memsz 0x00000330 flags r--

Dynamic Section:
  NEEDED      ld-uClibc.so.0
  SONAME      libc.so.0
  INIT        0x3412c
  HASH        0x114
  STRTAB      0x632c
  SYMTAB      0x219c
  STRSZ       0x2755
  SYMENT      0x10
  PLTGOT      0x40e7c
  PLTRELSZ    0x188
  PLTREL      0x11
  JMPREL      0x8eac
  REL         0x8a84
  RELSZ       0x428
  RELENT      0x8
  BIND_NOW    0x0
  FLAGS_1     0x1
  RELCOUNT    0x5b
private flags = 4000002: [Version4 EABI] [has entry point]


toolchain_build_armeb/gcc-4.2.1-final/gcc/libgcc/bpabi.o:     file format elf32-bigarm
private flags = 4000000: [Version4 EABI]

Has anyone else encountered this?

arm (little-endian) seems to build ok.

thanks
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Jonathan Nalley]

I have seen the exact same problem.  It doesn't matter if you select EABI or
not (the build doesn't complete either way).  I have been unable to build
when selecting "armeb" regardless of what other options I choose.  Little
Endian "arm" builds fine.  I have been trying to look into what might be
going wrong with little success.  I added "--disable-libmudflap" to the GCC
options, and that got me a little further in the build but it still failed
building gcc-final.

As I said, I have built the little endian toolchain with no issues at all.
I have used the little endian toolchain to build a kernel and u-boot
1.2.0which are both big endian.

One idea I had to simplify things is to modify the buildroot so that it
ALWAYS builds the little endian toolchain, but passes -mbig-endian when the
user selects "armeb".  This should greatly reduce the effort required to
test both "arm" and "armeb" since the same method/patches would be used for
both.  Thoughts?

On 10/15/07, Hamish Moffatt <hamish@cloud.net.au> wrote:
>
> I'm trying to build the current buildroot for armeb/xscale with the
> default settings (including gcc-4.2.1, uClibc 0.9.29) plus EABI.
>
> The build fails trying to link libgcc_s.so during gcc-4.2.1-final:
>
> /home/hamish/tmp/br/buildroot/toolchain_build_armeb/gcc-4.2.1-final/./gcc/xgcc
> -B/home/hamish/tmp/br/buildroot/toolchain_build_armeb/gcc-4.2.1-final/./gcc/
> -B/usr/armeb-linux-uclibcgnueabi/bin/ -B/usr/armeb-linux-uclibcgnueabi/lib/
> -isystem /usr/armeb-linux-uclibcgnueabi/include -isystem
> /usr/armeb-linux-uclibcgnueabi/sys-include -O2  -g -Os -DIN_GCC
> -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared
> -nodefaultlibs -Wl,--soname=libgcc_s.so.1
> -Wl,--version-script=libgcc/./libgcc.map -o
> ./libgcc_s.so.1.tmp  libgcc/./_udivsi3_s.o libgcc/./_divsi3_s.o
> libgcc/./_umodsi3_s.o libgcc/./_modsi3_s.o libgcc/./_bb_init_func_s.o
> libgcc/./_call_via_rX_s.o libgcc/./_interwork_call_via_rX_s.o
> libgcc/./_lshrdi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_ashldi3_s.o
> libgcc/./_negdf2_s.o libgcc/./_addsubdf3_s.o libgcc/./_muldivdf3_s.o
> libgcc/./_cmpdf2_s.o libgcc/./_unorddf2_s.o libgcc/./_fixdfsi_s.o
> libgcc/./_fixunsdfsi_s.o libgcc/./_truncdfsf2_s.o libgcc/./_negsf2_s.o
> libgcc/./_addsubsf3_s.o libgcc/./_muldivsf3_s.o libgcc/./_cmpsf2_s.o
> libgcc/./_unordsf2_s.o libgcc/./_fixsfsi_s.o libgcc/./_fixunssfsi_s.o
> libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundidf_s.o
> libgcc/./_floatundisf_s.o libgcc/./_aeabi_lcmp_s.o libgcc/./_aeabi_ulcmp_s.o
> libgcc/./_aeabi_ldivmod_s.o libgcc/./_aeabi_uldivmod_s.o
> libgcc/./_dvmd_lnx_s.o libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o
> libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
> libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
> libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
> libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
> libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
> libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
> libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
> libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
> libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o
> libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o
> libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o
> libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o
> libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o
> libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o
> libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o
> libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_fixxfdi_s.o
> libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o
> libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o
> libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o
> libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o
> libgcc/./_udivmoddi4_s.o libgcc/./bpabi_s.o libgcc/./unaligned-funcs_s.o
> libgcc/./unwind-arm_s.o libgcc/./libunwind_s.o libgcc/./pr-support_s.o
> libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1
> ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv
> ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
> /home/hamish/tmp/br/buildroot/build_armeb/staging_dir/lib/libc.so.0: could
> not read symbols: File in wrong format
>
> objdump shows that the files look correct and there's not a single
> little-endian .o
> in the tree so I'm a bit stumped.
>
> Comparing libc.so.0 with a random object out of the above list it seems
> the flags are identical.
> objdump -p says:
>
> /home/hamish/tmp/br/buildroot/build_armeb/staging_dir/lib/libc.so.0:
> file format elf32-bigarm
>
> Program Header:
> 0x70000001 off    0x00038858 vaddr 0x00038858 paddr 0x00038858 align 2**2
>          filesz 0x00000020 memsz 0x00000020 flags r--
>     PHDR off    0x00000034 vaddr 0x00000034 paddr 0x00000034 align 2**2
>          filesz 0x000000e0 memsz 0x000000e0 flags r-x
>   INTERP off    0x00038828 vaddr 0x00038828 paddr 0x00038828 align 2**3
>          filesz 0x00000018 memsz 0x00000018 flags r--
>     LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15
>          filesz 0x00038878 memsz 0x00038878 flags r-x
>     LOAD off    0x00038cd0 vaddr 0x00040cd0 paddr 0x00040cd0 align 2**15
>          filesz 0x00000690 memsz 0x0000484c flags rw-
> DYNAMIC off    0x00038dc4 vaddr 0x00040dc4 paddr 0x00040dc4 align 2**2
>          filesz 0x000000b8 memsz 0x000000b8 flags rw-
>    RELRO off    0x00038cd0 vaddr 0x00040cd0 paddr 0x00040cd0 align 2**0
>          filesz 0x00000330 memsz 0x00000330 flags r--
>
> Dynamic Section:
>   NEEDED      ld-uClibc.so.0
>   SONAME      libc.so.0
>   INIT        0x3412c
>   HASH        0x114
>   STRTAB      0x632c
>   SYMTAB      0x219c
>   STRSZ       0x2755
>   SYMENT      0x10
>   PLTGOT      0x40e7c
>   PLTRELSZ    0x188
>   PLTREL      0x11
>   JMPREL      0x8eac
>   REL         0x8a84
>   RELSZ       0x428
>   RELENT      0x8
>   BIND_NOW    0x0
>   FLAGS_1     0x1
>   RELCOUNT    0x5b
> private flags = 4000002: [Version4 EABI] [has entry point]
>
>
> toolchain_build_armeb/gcc-4.2.1-final/gcc/libgcc/bpabi.o:     file format
> elf32-bigarm
> private flags = 4000000: [Version4 EABI]
>
> Has anyone else encountered this?
>
> arm (little-endian) seems to build ok.
>
> thanks
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20071015/1cce2926/attachment.htm 

[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Ulf Samuelsson]

>I have seen the exact same problem.  It doesn't matter if you select EABI 
>or
> not (the build doesn't complete either way).  I have been unable to build
> when selecting "armeb" regardless of what other options I choose.  Little
> Endian "arm" builds fine.  I have been trying to look into what might be
> going wrong with little success.  I added "--disable-libmudflap" to the 
> GCC
> options, and that got me a little further in the build but it still failed
> building gcc-final.
>
> As I said, I have built the little endian toolchain with no issues at all.
> I have used the little endian toolchain to build a kernel and u-boot
> 1.2.0which are both big endian.
>
> One idea I had to simplify things is to modify the buildroot so that it
> ALWAYS builds the little endian toolchain, but passes -mbig-endian when 
> the
> user selects "armeb".  This should greatly reduce the effort required to
> test both "arm" and "armeb" since the same method/patches would be used 
> for
> both.  Thoughts?
>

I think this is possible to do this already,
select small endian, and make -mbig-endian an
extra TARGET_CFLAGS parameter.

This of course does not have the benefit of reducing the complexity of the 
toolchain.

Best Regards
Ulf Samuelsson

[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Hamish Moffatt]

On Mon, Oct 15, 2007 at 10:06:13AM -0500, Jonathan Nalley wrote:
> I have seen the exact same problem.  It doesn't matter if you select EABI or
> not (the build doesn't complete either way).  I have been unable to build
> when selecting "armeb" regardless of what other options I choose.  Little
> Endian "arm" builds fine.  I have been trying to look into what might be
> going wrong with little success.  I added "--disable-libmudflap" to the GCC
> options, and that got me a little further in the build but it still failed
> building gcc-final.

I concur; I can't get armeb to build in any configuration.

1. EABI: libgcc_s.so fails to link with incorrect file format error.
(With or without soft-float.)

2. OABI + linux 2.6.22 headers + soft-float: uClibc fails to build with
missing __NR_syscall:

libc/sysdeps/linux/arm/syscall.c: In function 'syscall':
libc/sysdeps/linux/arm/syscall.c:28: error: '__NR_syscall' undeclared (first use in this function)
libc/sysdeps/linux/arm/syscall.c:28: error: (Each undeclared identifier is reported only once
libc/sysdeps/linux/arm/syscall.c:28: error: for each function it appears in.)

3. OABI + linux 2.6.21.5 headers + soft-float: uClibc fails to build
with some missing floating-point symbols, possibly due to a mixup with
soft float options.

libc/libc_so.a(difftime.os): In function `difftime':
difftime.c:(.text+0x8): undefined reference to `__floatsidf'
difftime.c:(.text+0x2c): undefined reference to `__subdf3'
libc/libc_so.a(_fpmaxtostr.os): In function `_fpmaxtostr':
_fpmaxtostr.c:(.text+0xe0): undefined reference to `__nedf2'
_fpmaxtostr.c:(.text+0x104): undefined reference to `__eqdf2'
_fpmaxtostr.c:(.text+0x120): undefined reference to `__divdf3'
_fpmaxtostr.c:(.text+0x12c): undefined reference to `__ltdf2'
_fpmaxtostr.c:(.text+0x1e0): undefined reference to `__muldf3'
_fpmaxtostr.c:(.text+0x39c): undefined reference to `__gedf2'
_fpmaxtostr.c:(.text+0x42c): undefined reference to `__floatunsidf'
libc/libc_so.a(__psfs_do_numeric.os): In function `__psfs_do_numeric':
__psfs_do_numeric.c:(.text+0x54c): undefined reference to `__truncdfsf2'
libc/libc_so.a(strtof.os): In function `strtof':
strtof.c:(.text+0x1c): undefined reference to `__extendsfdf2'
libc/libc_so.a(__strtofpmax.os): In function `__strtofpmax':
__strtofpmax.c:(.text+0x154): undefined reference to `__adddf3'
/home/hamish/tmp/br/buildroot/build_armeb/staging_dir/usr/lib/gcc/armeb-linux-uclibc/4.2.1/libgcc.a(_fixunsdfsi.o): In function `__fixunsdfsi':
libgcc2.c:(.text+0x34): undefined reference to `__fixdfsi'
make[2]: *** [lib/libc.so] Error 1
make[1]: *** [lib/libc.so.0] Error 2

I didn't try OABI without soft-float yet, because I don't want to use
that configuration.

> As I said, I have built the little endian toolchain with no issues at all.
> I have used the little endian toolchain to build a kernel and u-boot
> 1.2.0which are both big endian.

What about user-space applications and uClibc? 

It should work. My last project used gcc-3.4.x with a default of
little-endian + -mbig-endian everywhere (kernel, uClibc) without issues.

> One idea I had to simplify things is to modify the buildroot so that it
> ALWAYS builds the little endian toolchain, but passes -mbig-endian when the
> user selects "armeb".  This should greatly reduce the effort required to
> test both "arm" and "armeb" since the same method/patches would be used for
> both.  Thoughts?

Sounds reasonable. In the meantime I wonder where the differences
between arm and armeb are...


thanks
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Hamish Moffatt]

On Tue, Oct 16, 2007 at 10:16:08AM +1000, Hamish Moffatt wrote:
> 2. OABI + linux 2.6.22 headers + soft-float: uClibc fails to build with
> missing __NR_syscall:
> 
> libc/sysdeps/linux/arm/syscall.c: In function 'syscall':
> libc/sysdeps/linux/arm/syscall.c:28: error: '__NR_syscall' undeclared (first use in this function)
> libc/sysdeps/linux/arm/syscall.c:28: error: (Each undeclared identifier is reported only once
> libc/sysdeps/linux/arm/syscall.c:28: error: for each function it appears in.)

Found the problem. The compiler was built for EABI even though I
selected OABI. This is because the compiler is choosing the ABI based on
the toolchain suffix.

If you change your configuration from EABI back to OABI, the toolchain suffix
is still set to the old default of uclibcgnueabi, so gcc is built
incorrectly.

So now it just fails like this:

> libc/libc_so.a(difftime.os): In function `difftime':
> difftime.c:(.text+0x8): undefined reference to `__floatsidf'
> difftime.c:(.text+0x2c): undefined reference to `__subdf3'
> libc/libc_so.a(_fpmaxtostr.os): In function `_fpmaxtostr':
> _fpmaxtostr.c:(.text+0xe0): undefined reference to `__nedf2'
> _fpmaxtostr.c:(.text+0x104): undefined reference to `__eqdf2'
> _fpmaxtostr.c:(.text+0x120): undefined reference to `__divdf3'
> _fpmaxtostr.c:(.text+0x12c): undefined reference to `__ltdf2'
> _fpmaxtostr.c:(.text+0x1e0): undefined reference to `__muldf3'
> _fpmaxtostr.c:(.text+0x39c): undefined reference to `__gedf2'
> _fpmaxtostr.c:(.text+0x42c): undefined reference to `__floatunsidf'
> libc/libc_so.a(__psfs_do_numeric.os): In function `__psfs_do_numeric':
> __psfs_do_numeric.c:(.text+0x54c): undefined reference to `__truncdfsf2'
> libc/libc_so.a(strtof.os): In function `strtof':
> strtof.c:(.text+0x1c): undefined reference to `__extendsfdf2'
> libc/libc_so.a(__strtofpmax.os): In function `__strtofpmax':
> __strtofpmax.c:(.text+0x154): undefined reference to `__adddf3'
> /home/hamish/tmp/br/buildroot/build_armeb/staging_dir/usr/lib/gcc/armeb-linux-uclibc/4.2.1/libgcc.a(_fixunsdfsi.o): In function `__fixunsdfsi':
> libgcc2.c:(.text+0x34): undefined reference to `__fixdfsi'
> make[2]: *** [lib/libc.so] Error 1
> make[1]: *** [lib/libc.so.0] Error 2

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Hamish Moffatt]

On Tue, Oct 16, 2007 at 01:42:33PM +1000, Hamish Moffatt wrote:
> So now it just fails like this:
> 
> > libc/libc_so.a(difftime.os): In function `difftime':
> > difftime.c:(.text+0x8): undefined reference to `__floatsidf'
> > difftime.c:(.text+0x2c): undefined reference to `__subdf3'
> > libc/libc_so.a(_fpmaxtostr.os): In function `_fpmaxtostr':
> > _fpmaxtostr.c:(.text+0xe0): undefined reference to `__nedf2'
> > _fpmaxtostr.c:(.text+0x104): undefined reference to `__eqdf2'
> > _fpmaxtostr.c:(.text+0x120): undefined reference to `__divdf3'
> > _fpmaxtostr.c:(.text+0x12c): undefined reference to `__ltdf2'
> > _fpmaxtostr.c:(.text+0x1e0): undefined reference to `__muldf3'
> > _fpmaxtostr.c:(.text+0x39c): undefined reference to `__gedf2'
> > _fpmaxtostr.c:(.text+0x42c): undefined reference to `__floatunsidf'
> > libc/libc_so.a(__psfs_do_numeric.os): In function `__psfs_do_numeric':
> > __psfs_do_numeric.c:(.text+0x54c): undefined reference to `__truncdfsf2'
> > libc/libc_so.a(strtof.os): In function `strtof':
> > strtof.c:(.text+0x1c): undefined reference to `__extendsfdf2'
> > libc/libc_so.a(__strtofpmax.os): In function `__strtofpmax':
> > __strtofpmax.c:(.text+0x154): undefined reference to `__adddf3'
> > /home/hamish/tmp/br/buildroot/build_armeb/staging_dir/usr/lib/gcc/armeb-linux-uclibc/4.2.1/libgcc.a(_fixunsdfsi.o): In function `__fixunsdfsi':
> > libgcc2.c:(.text+0x34): undefined reference to `__fixdfsi'
> > make[2]: *** [lib/libc.so] Error 1
> > make[1]: *** [lib/libc.so.0] Error 2

And this is caused by soft-float.

Summary of situation:

arm EABI hard-float: builds.

armeb EABI hard-float: libgcc_s.so fails to link due to incorrect file
format of libc.so

arm/armeb OABI hard-float: builds.
arm/armeb OABI soft-float: fails as above (both endians fail the same
way).

I haven't tried soft-float EABI.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Ulf Samuelsson]

> And this is caused by soft-float.
> 
> Summary of situation:
> 
> arm EABI hard-float: builds.
> 
> armeb EABI hard-float: libgcc_s.so fails to link due to incorrect file
> format of libc.so
> 
> arm/armeb OABI hard-float: builds.
> arm/armeb OABI soft-float: fails as above (both endians fail the same
> way).
> 
> I haven't tried soft-float EABI.

I tried the ARM integrator, on Bernhards recommendation
a few weeks ago, and that would build an EABI 4.2.1 softfloat toolchain,
a few days later, it was broken again.
I think that there must be some uClibc options which should be set
in the correct way for the build to complete.

Best Regards
Ulf Samuelsson

[Buildroot] buildroot for armeb, gcc-4.2.1 fails to build

[Hamish Moffatt]

On Tue, Oct 16, 2007 at 08:00:07AM +0200, Ulf Samuelsson wrote:
>> And this is caused by soft-float.
>> Summary of situation:
>> arm EABI hard-float: builds.
>> armeb EABI hard-float: libgcc_s.so fails to link due to incorrect file
>> format of libc.so
>> arm/armeb OABI hard-float: builds.
>> arm/armeb OABI soft-float: fails as above (both endians fail the same
>> way).
>> I haven't tried soft-float EABI.
>
> I tried the ARM integrator, on Bernhards recommendation
> a few weeks ago, and that would build an EABI 4.2.1 softfloat toolchain,
> a few days later, it was broken again.
> I think that there must be some uClibc options which should be set
> in the correct way for the build to complete.

I just built arm + EABI + soft-float + 4.2.1 successfully.
I'm trying armeb now, although I'm not hopefully given that the same
configuration except for soft-float failed (with non-float-related
errors).

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] PATCH: buildroot for armeb, gcc-4.2.1 fails to build

[Hamish Moffatt]

On Tue, Oct 16, 2007 at 10:16:08AM +1000, Hamish Moffatt wrote:
> 3. OABI + linux 2.6.21.5 headers + soft-float: uClibc fails to build
> with some missing floating-point symbols, possibly due to a mixup with
> soft float options.
> 
> libc/libc_so.a(difftime.os): In function `difftime':
> difftime.c:(.text+0x8): undefined reference to `__floatsidf'
> difftime.c:(.text+0x2c): undefined reference to `__subdf3'
> libc/libc_so.a(_fpmaxtostr.os): In function `_fpmaxtostr':

The patch below makes arm & armeb build for OABI with soft floats with
gcc 4.2.1.

It's a massaged version of a patch posted here last year:
http://osdir.com/ml/lib.uclibc.buildroot/2006-12/msg00076.html

Index: toolchain/gcc/4.2.1/910-soft-float.patch
===================================================================
--- toolchain/gcc/4.2.1/910-soft-float.patch    (revision 0)
+++ toolchain/gcc/4.2.1/910-soft-float.patch    (revision 0)
@@ -0,0 +1,26 @@
+--- gcc-4.2-20061205/gcc/config/arm/t-linux    2006-12-08 15:18:33.000000000 -0800
++++ gcc-4.2-20061205/gcc/config/arm/t-linux    2006-12-08 15:18:33.000000000 -0800
+@@ -4,7 +4,10 @@
+ LIBGCC2_DEBUG_CFLAGS = -g0
+ 
+ LIB1ASMSRC = arm/lib1funcs.asm
+-LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx
++LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx \
++      _negdf2 _addsubdf3 _muldivdf3 _cmpdf2 _unorddf2 _fixdfsi _fixunsdfsi \
++      _truncdfsf2 _negsf2 _addsubsf3 _muldivsf3 _cmpsf2 _unordsf2 \
++      _fixsfsi _fixunssfsi _floatdidf _floatundidf _floatdisf _floatundisf
+ 
+ # MULTILIB_OPTIONS = mhard-float/msoft-float
+ # MULTILIB_DIRNAMES = hard-float soft-float
+
+--- gcc-4.2-20061205/gcc/config/arm/linux-elf.h        2006-12-08 15:18:33.000000000 -0800
++++ gcc-4.2-20061205/gcc/config/arm/linux-elf.h        2006-12-08 15:18:33.000000000 -0800
+@@ -63,7 +63,7 @@
+    %{shared:-lc} \
+    %{!shared:%{profile:-lc_p}%{!profile:-lc}}"
+ 
+-#define LIBGCC_SPEC "%{msoft-float:-lfloat} %{mfloat-abi=soft*:-lfloat} -lgcc"
++#define LIBGCC_SPEC "-lgcc"
+ 
+ #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+ 

-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>