[Buildroot] [PATCH 1/1] Fix elf2flt build

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Douglas RAILLARD]

Add -ldl to fix elf2flt build, because libbfd
uses dlopen and friends for plugin loading

Signed-off-by: Douglas RAILLARD <public.douglas.raillard@gmail.com>
---
 package/elf2flt/elf2flt.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/elf2flt/elf2flt.mk b/package/elf2flt/elf2flt.mk
index 0233ed5..d3ff293 100644
--- a/package/elf2flt/elf2flt.mk
+++ b/package/elf2flt/elf2flt.mk
@@ -21,6 +21,6 @@ HOST_ELF2FLT_CONF_OPTS = \
 	--with-libiberty=$(HOST_BINUTILS_DIR)/libiberty/libiberty.a \
 	--target=$(GNU_TARGET_NAME)
 
-HOST_ELF2FLT_CONF_ENV = LIBS=-lz
+HOST_ELF2FLT_CONF_ENV = LIBS="-lz -ldl"
 
 $(eval $(host-autotools-package))
-- 
2.5.0

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Thomas Petazzoni]

Douglas,

On Thu, 27 Aug 2015 18:47:17 +0200, Douglas RAILLARD wrote:
> Add -ldl to fix elf2flt build, because libbfd
> uses dlopen and friends for plugin loading
> 
> Signed-off-by: Douglas RAILLARD <public.douglas.raillard@gmail.com>

Thanks for this patch. Great to see that there is some interest in
noMMU architecture. Which architecture are you working on?

I'm not able to reproduce the problem: here host-elf2flt builds fine.
However the build of an ARM Cortex-M3 toolchain fails during the uClibc
build (which takes place *after* host-elf2flt is built).

Thanks!

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

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Douglas RAILLARD]

Thomas,


> Thanks for this patch. Great to see that there is some interest in
> noMMU architecture. Which architecture are you working on?

Im actually working on the STM32F429 Cortex M4 with the
stm32f429-discovery board from STMicroelectronics.
It seems that things are also moving on the kernel side
for this arch and board.


> I'm not able to reproduce the problem: here host-elf2flt builds fine.

I did not find any failure for elf2flt on the autobuild server,
but without the patch, make complains.
I have not checked if libbfd can be configured without plugin
support, but it fails with my configuration
(sorry for untranslated french diagnostic error):
/usr/bin/gcc -Wall -O2 -I/working_dir/buildroot/output/host/usr/include -
L/working_dir/buildroot/output/host/lib -
L/working_dir/buildroot/output/host/usr/lib -Wl,-
rpath,/working_dir/buildroot/output/host/usr/lib -o elf2flt elf2flt.o 
compress.o stubs.o -lc -lz /working_dir/buildroot/output/build/host-
binutils-2.24/bfd/libbfd.a /working_dir/buildroot/output/build/host-
binutils-2.24/libiberty/libiberty.a -lz
/working_dir/buildroot/output/build/host-binutils-2.24/bfd/libbfd.a(plugin.o): 
in fonction ? try_load_plugin ?:
plugin.c:(.text+0x1db): undefined reference to ? dlopen ?
plugin.c:(.text+0x1f1): undefined reference to ? dlsym ?
plugin.c:(.text+0x270): undefined reference to ? dlerror ?
collect2: error: ld a retourn? 1 code d'?tat d'ex?cution
Makefile:75 : la recette pour la cible ? elf2flt ? a ?chou?e
make[1]: *** [elf2flt] Erreur 1
make[1] : on quitte le r?pertoire ? /working_dir/buildroot/output/build/host-
elf2flt-21c6a41885ad544763ccd19883c1353f3b0b7a47 ?


> However the build of an ARM Cortex-M3 toolchain fails during the uClibc
> build (which takes place *after* host-elf2flt is built).

There are indeed problems when some toolchain options are selected, 
so I managed to leave them out for the moment to focus on getting 
something built. Here is my buildroot configuration generated with
make savedefconfig:
BR2_arm=y
BR2_cortex_m3=y
BR2_ARM_INSTRUCTIONS_THUMB2=y
BR2_GLOBAL_PATCH_DIR="../patch"
BR2_UCLIBC_VERSION_0_9_33=y
BR2_UCLIBC_CONFIG="package/uclibc/uClibc-ng.config"
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PTHREADS_NONE=y
BR2_TOOLCHAIN_BUILDROOT_USE_SSP=y
BR2_GCC_ENABLE_LTO=y
BR2_PACKAGE_HOST_ELF2FLT=y
BR2_PACKAGE_HOST_GDB=y
BR2_PACKAGE_HOST_GDB_TUI=y
BR2_PACKAGE_HOST_GDB_PYTHON=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="master"
BR2_LINUX_KERNEL_DEFCONFIG="stm32"
BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y
BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="xipImage"
BR2_TARGET_ROOTFS_ROMFS=y
# BR2_TARGET_ROOTFS_TAR is not set
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="stm32f429-discovery"
BR2_PACKAGE_HOST_UBOOT_TOOLS=y


Moreover, there are some other issues with elf2flt when the toolchain is built
(one of the first target binary which get compiled after uClibc is getconf, 
part of uClibc I guess),
I am writing another email for that 


Regards,

Douglas

Le jeudi 27 ao?t 2015 20:35:01, vous avez ?crit :

> Douglas,
> 
> On Thu, 27 Aug 2015 18:47:17 +0200, Douglas RAILLARD wrote:

> > Add -ldl to fix elf2flt build, because libbfd
> > uses dlopen and friends for plugin loading
> > 
> > Signed-off-by: Douglas RAILLARD <public.douglas.raillard@gmail.com>

> 
> Thanks for this patch. Great to see that there is some interest in
> noMMU architecture. Which architecture are you working on?
> 
> I'm not able to reproduce the problem: here host-elf2flt builds fine.
> However the build of an ARM Cortex-M3 toolchain fails during the uClibc
> build (which takes place *after* host-elf2flt is built).
> 
> Thanks!
> 
> Thomas

-- 

Douglas RAILLARD

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Thomas Petazzoni]

Douglas,

Please do not reply to me directly: keep the list in Cc so that others
can continue to participate to the discussion. Thanks!

On Thu, 27 Aug 2015 20:56:42 +0200, Douglas RAILLARD wrote:
> Thomas,
> 
> > Thanks for this patch. Great to see that there is some interest in
> > noMMU architecture. Which architecture are you working on?
> 
> Im actually working on the STM32F429 Cortex M4 with the
> stm32f429-discovery board from STMicroelectronics.

Nice!

> It seems that things are also moving on the kernel side
> for this arch and board.

Yes, ST is pushing patches to the upstream kernel for this platform.

> > I'm not able to reproduce the problem: here host-elf2flt builds fine.
> 
> I did not find any failure for elf2flt on the autobuild server,
> but without the patch, make complains.
> I have not checked if libbfd can be configured without plugin
> support, but it fails with my configuration
> (sorry for untranslated french diagnostic error):
> /usr/bin/gcc -Wall -O2 -I/working_dir/buildroot/output/host/usr/include -L/working_dir/buildroot/output/host/lib -L/working_dir/buildroot/output/host/usr/lib -Wl,-rpath,/working_dir/buildroot/output/host/usr/lib -o elf2flt elf2flt.o compress.o stubs.o -lc -lz /working_dir/buildroot/output/build/host-binutils-2.24/bfd/libbfd.a /working_dir/buildroot/output/build/host-binutils-2.24/libiberty/libiberty.a -lz
> /working_dir/buildroot/output/build/host-binutils-2.24/bfd/libbfd.a(plugin.o): in fonction ? try_load_plugin ?:
> plugin.c:(.text+0x1db): undefined reference to ? dlopen ?
> plugin.c:(.text+0x1f1): undefined reference to ? dlsym ?
> plugin.c:(.text+0x270): undefined reference to ? dlerror ?
> collect2: error: ld a retourn? 1 code d'?tat d'ex?cution
> Makefile:75 : la recette pour la cible ? elf2flt ? a ?chou?e
> make[1]: *** [elf2flt] Erreur 1
> make[1] : on quitte le r?pertoire ? /working_dir/buildroot/output/build/host-elf2flt-21c6a41885ad544763ccd19883c1353f3b0b7a47 ?

I have not reproduced this issue, but it might be caused by the fact
that you've enabled LTO support in gcc. I'll try again with LTO
enabled, just to narrow down the problem.

> > However the build of an ARM Cortex-M3 toolchain fails during the uClibc
> > build (which takes place *after* host-elf2flt is built).
> 
> There are indeed problems when some toolchain options are selected, 
> so I managed to leave them out for the moment to focus on getting 
> something built. Here is my buildroot configuration generated with
> make savedefconfig:
> BR2_arm=y
> BR2_cortex_m3=y
> BR2_ARM_INSTRUCTIONS_THUMB2=y
> BR2_GLOBAL_PATCH_DIR="../patch"
> BR2_UCLIBC_VERSION_0_9_33=y
> BR2_UCLIBC_CONFIG="package/uclibc/uClibc-ng.config"

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 ?

> BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
> BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
> BR2_PTHREADS_NONE=y

Any reason to disable thread support?

> BR2_TOOLCHAIN_BUILDROOT_USE_SSP=y
> BR2_GCC_ENABLE_LTO=y
> BR2_PACKAGE_HOST_ELF2FLT=y
> BR2_PACKAGE_HOST_GDB=y
> BR2_PACKAGE_HOST_GDB_TUI=y
> BR2_PACKAGE_HOST_GDB_PYTHON=y
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_GIT=y
> BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
> BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="master"
> BR2_LINUX_KERNEL_DEFCONFIG="stm32"
> BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y
> BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="xipImage"
> BR2_TARGET_ROOTFS_ROMFS=y
> # BR2_TARGET_ROOTFS_TAR is not set
> BR2_TARGET_UBOOT=y
> BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
> BR2_TARGET_UBOOT_BOARD_DEFCONFIG="stm32f429-discovery"
> BR2_PACKAGE_HOST_UBOOT_TOOLS=y
> 
> Moreover, there are some other issues with elf2flt when the toolchain is built
> (one of the first target binary which get compiled after uClibc is getconf, part of uClibc I guess),
> I am writing another email for that :)

Ok, thanks!

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!

Best regards,

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

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Douglas RAILLARD]

Thomas,

On Friday 28 August 2015 10:09:32, Thomas Petazzoni wrote:
> Douglas,
> 
> Please do not reply to me directly: keep the list in Cc so that others
> can continue to participate to the discussion. Thanks!
> 
Sorry, messed up with my mailer, previous email here for reference: 
http://lists.busybox.net/pipermail/buildroot/2015-August/138057.html


> > > However the build of an ARM Cortex-M3 toolchain fails during the uClibc
> > > build (which takes place *after* host-elf2flt is built).
> > 
> > There are indeed problems when some toolchain options are selected,
> > so I managed to leave them out for the moment to focus on getting
> > something built. Here is my buildroot configuration generated with
> > make savedefconfig:
> > BR2_arm=y
> > BR2_cortex_m3=y
> > BR2_ARM_INSTRUCTIONS_THUMB2=y
> > BR2_GLOBAL_PATCH_DIR="../patch"
> > BR2_UCLIBC_VERSION_0_9_33=y
> > BR2_UCLIBC_CONFIG="package/uclibc/uClibc-ng.config"
> 
> 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:

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


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

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

Best regards,

Douglas

-- 

Douglas RAILLARD

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Thomas Petazzoni]

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

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

Thanks,

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

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Waldemar Brodkorb]

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

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Douglas RAILLARD]

On 28/08/2015 15:01, Waldemar Brodkorb wrote:
> Please disable UCLIBC_HAS_CONTEXT_FUNCS, as the code is not thumb
> ready. I'll accept any patches for this 

Works better without UCLIBC_HAS_CONTEXT_FUNCS

> NPTL is not thumb ready, please use LINUXTHREADS.OLD for ARM no-MMU
> or send a fix :)

Still fails with LINUXTHREADS_OLD:
/working_dir/buildroot/output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc -c libpthread/linuxthreads.old/mutex.c -o libpthread/linuxthreads.old/mutex.os -Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin -fno-asm -fmerge-all-constants -msoft-float -std=gnu99 -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./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/arm -I./libpthread/linuxthreads.old/sysdeps/arm -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -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/in
clude -I/working_dir/buildroot/output/build/linux-headers-4.1.4/usr/include/ -DNDEBUG -DNOT_IN_libc -DIS_IN_libpthread -fstack-protector-all -DIN_LIB=libpthread -fPIC -MT libpthread/linuxthreads.old/mutex.os -MD -MP -MF libpthread/linuxthreads.old/.mutex.os.dep
/tmp/ccWVQC5r.s: Assembler messages:
/tmp/ccWVQC5r.s:34: Error: selected processor does not support ARM opcodes
/tmp/ccWVQC5r.s:35: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r3,r3,[r0]'
/tmp/ccWVQC5r.s:36: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r0,pc,#1'
/tmp/ccWVQC5r.s:37: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r0'
/tmp/ccWVQC5r.s:151: Error: selected processor does not support ARM opcodes
/tmp/ccWVQC5r.s:152: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r3,r3,[r0]'
/tmp/ccWVQC5r.s:153: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r0,pc,#1'
/tmp/ccWVQC5r.s:154: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r0'
Makerules:383: recipe for target 'libpthread/linuxthreads.old/mutex.os' failed
make[1]: *** [libpthread/linuxthreads.old/mutex.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

It seems that the problem stems from libpthread/linuxthreads.old/sysdeps/arm/pt-machine.h in testandset function:
     83         "\tswp %0, %2, [%3]\n"
     84         "\torr %1, pc, #1\n"
     85         "\tbx %1\n"


Is it still the good place to send such reports or should I post them somewhere else ? (or in a new thread)


Best regards,

Douglas


-- 

Douglas RAILLARD

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Waldemar Brodkorb]

Hi,
Douglas RAILLARD wrote,

> On 28/08/2015 15:01, Waldemar Brodkorb wrote:
> > Please disable UCLIBC_HAS_CONTEXT_FUNCS, as the code is not thumb
> > ready. I'll accept any patches for this 
> 
> Works better without UCLIBC_HAS_CONTEXT_FUNCS
> 
> > NPTL is not thumb ready, please use LINUXTHREADS.OLD for ARM no-MMU
> > or send a fix :)
> 
> Still fails with LINUXTHREADS_OLD:
> /working_dir/buildroot/output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc -c libpthread/linuxthreads.old/mutex.c -o libpthread/linuxthreads.old/mutex.os -Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin -fno-asm -fmerge-all-constants -msoft-float -std=gnu99 -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./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/arm -I./libpthread/linuxthreads.old/sysdeps/arm -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -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/in
> clude -I/working_dir/buildroot/output/build/linux-headers-4.1.4/usr/include/ -DNDEBUG -DNOT_IN_libc -DIS_IN_libpthread -fstack-protector-all -DIN_LIB=libpthread -fPIC -MT libpthread/linuxthreads.old/mutex.os -MD -MP -MF libpthread/linuxthreads.old/.mutex.os.dep
> /tmp/ccWVQC5r.s: Assembler messages:
> /tmp/ccWVQC5r.s:34: Error: selected processor does not support ARM opcodes
> /tmp/ccWVQC5r.s:35: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r3,r3,[r0]'
> /tmp/ccWVQC5r.s:36: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r0,pc,#1'
> /tmp/ccWVQC5r.s:37: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r0'
> /tmp/ccWVQC5r.s:151: Error: selected processor does not support ARM opcodes
> /tmp/ccWVQC5r.s:152: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r3,r3,[r0]'
> /tmp/ccWVQC5r.s:153: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r0,pc,#1'
> /tmp/ccWVQC5r.s:154: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r0'
> Makerules:383: recipe for target 'libpthread/linuxthreads.old/mutex.os' failed
> make[1]: *** [libpthread/linuxthreads.old/mutex.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
> 
> It seems that the problem stems from libpthread/linuxthreads.old/sysdeps/arm/pt-machine.h in testandset function:
>      83         "\tswp %0, %2, [%3]\n"
>      84         "\torr %1, pc, #1\n"
>      85         "\tbx %1\n"
> 
> 
> Is it still the good place to send such reports or should I post them somewhere else ? (or in a new thread)

Okay, for me.
Please enable COMPILE_IN_THUMB_MODE in your uClibc config. It is
missing in the generated config. Would be cool if you prepare a
patch with the two fixes.

best regards
 Waldemar

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Douglas RAILLARD]

On 31/08/2015 08:05, Waldemar Brodkorb wrote:
> Hi,
> Douglas RAILLARD wrote,
> 
>> On 28/08/2015 15:01, Waldemar Brodkorb wrote:
>>> Please disable UCLIBC_HAS_CONTEXT_FUNCS, as the code is not thumb
>>> ready. I'll accept any patches for this 
>>
>> Works better without UCLIBC_HAS_CONTEXT_FUNCS
>>
>>> NPTL is not thumb ready, please use LINUXTHREADS.OLD for ARM no-MMU
>>> or send a fix :)
>>
>> Still fails with LINUXTHREADS_OLD:
>> /working_dir/buildroot/output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc -c libpthread/linuxthreads.old/mutex.c -o libpthread/linuxthreads.old/mutex.os -Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin -fno-asm -fmerge-all-constants -msoft-float -std=gnu99 -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./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/arm -I./libpthread/linuxthreads.old/sysdeps/arm -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -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-uclibcgnue
 abi/4.9.3
/in
>> clude -I/working_dir/buildroot/output/build/linux-headers-4.1.4/usr/include/ -DNDEBUG -DNOT_IN_libc -DIS_IN_libpthread -fstack-protector-all -DIN_LIB=libpthread -fPIC -MT libpthread/linuxthreads.old/mutex.os -MD -MP -MF libpthread/linuxthreads.old/.mutex.os.dep
>> /tmp/ccWVQC5r.s: Assembler messages:
>> /tmp/ccWVQC5r.s:34: Error: selected processor does not support ARM opcodes
>> /tmp/ccWVQC5r.s:35: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r3,r3,[r0]'
>> /tmp/ccWVQC5r.s:36: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r0,pc,#1'
>> /tmp/ccWVQC5r.s:37: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r0'
>> /tmp/ccWVQC5r.s:151: Error: selected processor does not support ARM opcodes
>> /tmp/ccWVQC5r.s:152: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r3,r3,[r0]'
>> /tmp/ccWVQC5r.s:153: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r0,pc,#1'
>> /tmp/ccWVQC5r.s:154: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r0'
>> Makerules:383: recipe for target 'libpthread/linuxthreads.old/mutex.os' failed
>> make[1]: *** [libpthread/linuxthreads.old/mutex.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
>>
>> It seems that the problem stems from libpthread/linuxthreads.old/sysdeps/arm/pt-machine.h in testandset function:
>>      83         "\tswp %0, %2, [%3]\n"
>>      84         "\torr %1, pc, #1\n"
>>      85         "\tbx %1\n"
>>
>>
>> Is it still the good place to send such reports or should I post them somewhere else ? (or in a new thread)
> 
> Okay, for me.
> Please enable COMPILE_IN_THUMB_MODE in your uClibc config. It is
> missing in the generated config. Would be cool if you prepare a
> patch with the two fixes.

With COMPILE_IN_THUMB_MODE uClibc-ng now compiles cleanly, thanks for
your help :)
I will send a patch in the next few days for the config file of
uClibc-ng when compiling for Cortex M3.

BTW: Are there any benefits in using 2.24 (default) instead of 2.25.1
and also gcc 4.9.x (default) instead of gcc 5.x ?


Best regards,
Douglas


-- 

Douglas RAILLARD

[Buildroot] [PATCH 1/1] Fix elf2flt build

[Thomas Petazzoni]

Douglas,

On Mon, 31 Aug 2015 14:08:16 +0200, Douglas RAILLARD wrote:

> BTW: Are there any benefits in using 2.24 (default) instead of 2.25.1
> and also gcc 4.9.x (default) instead of gcc 5.x ?

It's just because when it comes to toolchain components, we are a bit
conservative, and generally default to the version just before the last
one. New version of gcc/binutils often exhibits some issues on
non-mainstream architectures, so this policy allows to wait a bit that
the big issues are found/fixed before we use them as the default.

For example, gcc 5.x has more strict rules which causes many packages
to not build anymore. Hence, we cannot use it as the default for the
moment.

Best regards,

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