From: Waldemar Brodkorb <wbx@openadk.org>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] Fix elf2flt build
Date: Fri, 28 Aug 2015 15:01:09 +0200 [thread overview]
Message-ID: <20150828130109.GA2808@waldemar-brodkorb.de> (raw)
In-Reply-To: <20150828132047.5ef4eec8@free-electrons.com>
Hi Douglas, Thomas,
Thomas Petazzoni wrote,
> Douglas,
>
> On Fri, 28 Aug 2015 12:17:40 +0200, Douglas RAILLARD wrote:
>
> > > This seems weird: using uClibc 0.9.33 with the configuration file for
> > > uClibc-ng. Have you had any problem with uClibc-ng that made you go
> > > back to uClibc 0.9.33 ?
> >
> > Indeed, I did not pay attention to it in the first place as I wanted to use as
> > much default as possible.
> > uClibc-ng does not compile with my configuration (same as before but with
> > uClibc-ng instead of uClibc 0.9.33), I have not tried to investigate this issue yet:
>
> I would suggest to use uClibc-ng. The upstream uClibc developers are
> not really active anymore, while the uClibc-ng (Waldemar) is very
> active, and is following/helping the Buildroot development as well. I'm
> sure he will be interested by your reports. I've added him in Cc.
>
> > make[1]: Entering directory '/working_dir/buildroot/output/build/uclibc-1.0.5'
> > /working_dir/buildroot/output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc -c libc/sysdeps/linux/arm/setcontext.S -o libc/sysdeps/linux/arm/setcontext.os -Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin -fno-asm -fmerge-all-constants -msoft-float -mlittle-endian -fstack-protector -nostdinc -I./include -I./include -include libc-symbols.h -I./libc/sysdeps/linux/arm -I./libc/sysdeps/linux -I./ldso/ldso/arm -I./ldso/include -I. -DSTATIC -Os -fstrict-aliasing -I./libc/sysdeps/linux/common -isystem /working_dir/buildroot/output/host/usr/lib/gcc/arm-buildroot-uclinux-uclibcgnueabi/4.9.3/include-fixed -isystem /working_dir/buildroot/output/host/usr/lib/gcc/arm-buildroot-uclinux-uclibcgnueabi/4.9.3/include -I/working_dir/buildroot/output/build/linux-headers-4.1.4/usr/include/ -DNDEBUG -DIN_LIB=libc -fPIC -MT libc/sysdeps/linux/arm/setcontext.os -MD -MP -MF libc/sysdeps/linux/arm/.setcontext.os.dep -D__ASSEMBLER__ -Wa,--noexecstack
> > libc/sysdeps/linux/arm/setcontext.S: Assembler messages:
> > libc/sysdeps/linux/arm/setcontext.S:63: Error: LR and PC should not both be in register list -- `ldmia r14,{r14,pc}'
> > Makerules:386: recipe for target 'libc/sysdeps/linux/arm/setcontext.os' failed
> > make[1]: *** [libc/sysdeps/linux/arm/setcontext.os] Error 1
> > make[1]: Leaving directory '/working_dir/buildroot/output/build/uclibc-1.0.5'
> > package/pkg-generic.mk:156: recipe for target '/working_dir/buildroot/output/build/uclibc-1.0.5/.stamp_built' failed
> > make: *** [/working_dir/buildroot/output/build/uclibc-1.0.5/.stamp_built] Error 2
Please disable UCLIBC_HAS_CONTEXT_FUNCS, as the code is not thumb
ready. I'll accept any patches for this :)
> >
> > > > BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
> > > > BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
> > > > BR2_PTHREADS_NONE=y
> > >
> > > Any reason to disable thread support?
> > It fails with NPTL thread support enabled (and also with every other threading backend).
> > Same configuration with uClibc 0.9.33 and NPTL thread, I did not try to solve this
> > issue yet:
> >
> > make[1]: Entering directory '/working_dir/buildroot/output/build/uclibc-0.9.33.2'
> > AR cr lib/libcrypt.a
> > STRIP -x -R .note -R .comment lib/libcrypt.a
> > AR cr lib/libm.a
> > STRIP -x -R .note -R .comment lib/libm.a
> > AR cr lib/libnsl.a
> > STRIP -x -R .note -R .comment lib/libnsl.a
> > AR cr lib/libresolv.a
> > STRIP -x -R .note -R .comment lib/libresolv.a
> > AR cr lib/libutil.a
> > STRIP -x -R .note -R .comment lib/libutil.a
> > AS libpthread/nptl/sysdeps/arm/pthread_spin_lock.os -DSTATIC -DHAVE_FORCED_UNWIND -DNDEBUG -D__USE_STDIO_FUTEXES__ -D__ASSEMBLER__ -DNOT_IN_libc -DIS_IN_libpthread
> > libpthread/nptl/sysdeps/arm/pthread_spin_lock.S: Assembler messages:
> > libpthread/nptl/sysdeps/arm/pthread_spin_lock.S:26: Error: selected processor does not support Thumb mode `swp r2,r1,[r0]'
> > libpthread/nptl/sysdeps/arm/pthread_spin_lock.S:27: Error: instruction not supported in Thumb16 mode -- `teq r2,#0'
> > Makerules:362: recipe for target 'libpthread/nptl/sysdeps/arm/pthread_spin_lock.os' failed
> > make[1]: *** [libpthread/nptl/sysdeps/arm/pthread_spin_lock.os] Error 1
> > make[1]: Leaving directory '/working_dir/buildroot/output/build/uclibc-0.9.33.2'
> > package/pkg-generic.mk:156: recipe for target '/working_dir/buildroot/output/build/uclibc-0.9.33.2/.stamp_built' failed
> > make: *** [/working_dir/buildroot/output/build/uclibc-0.9.33.2/.stamp_built] Error 2
>
> Another thing for Waldemar :-)
NPTL is not thumb ready, please use LINUXTHREADS.OLD for ARM no-MMU
or send a fix :)
> > > To tell the truth, ARM noMMU support in Buildroot is very much a work
> > > in progress. We have had only some initial Cortex-M3 patches, and a lot
> > > of work remain to be done to make it really usable. Your
> > > patches/reports are definitely welcome!
> >
> > I plan to add support the smt32f429-discovery board with as much new
> > stuff as possible (new kernel, new toolchain, new Busybox, new U-boot), because
> > I started from this: https://github.com/jserv/stm32f429-linux-builder and after some
> > research, I felt that Buildroot was in the same vein, but much more integrated and also
> > widespread so this was the way to go for that kind of job.
>
> Great idea! Looking forward to seeing patches going in this direction!
BTW: I have a working elf2flt git repo here:
http://cgit.openadk.org/cgi/cgit/elf2flt.git
At least working for m68k/coldfire and h8/300.
I have not done runtime testing on ARM, yet.
But the required patch is in:
http://cgit.openadk.org/cgi/cgit/elf2flt.git/commit/?id=830762b7875194677bf0ed41af44758d8323260f
dito
Waldemar
next prev parent reply other threads:[~2015-08-28 13:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 16:47 [Buildroot] [PATCH 1/1] Fix elf2flt build Douglas RAILLARD
2015-08-27 18:35 ` Thomas Petazzoni
2015-08-27 21:00 ` Douglas RAILLARD
[not found] ` <6966330.pLhB8QsgjT@raillard-dv6>
2015-08-28 8:09 ` Thomas Petazzoni
2015-08-28 10:17 ` Douglas RAILLARD
2015-08-28 11:20 ` Thomas Petazzoni
2015-08-28 13:01 ` Waldemar Brodkorb [this message]
2015-08-30 15:43 ` Douglas RAILLARD
2015-08-31 6:05 ` Waldemar Brodkorb
2015-08-31 12:08 ` Douglas RAILLARD
2015-08-31 12:28 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150828130109.GA2808@waldemar-brodkorb.de \
--to=wbx@openadk.org \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.