Skip to contentSkip to conversation

Fix elf2flt build

PATCH New Douglas RAILLARD 3 participants 11 messages Aug 27, 2015 – Aug 31, 2015 1 message not in the archive

lore
Share & tools
lore

Douglas RAILLARD

author
#0 lore raw

PATCH 1/1 Fix elf2flt build

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

Signed-off-by Douglas RAILLARD <[email protected]>
---
 package/elf2flt/elf2flt.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
package/elf2flt/elf2flt.mk +1 -1
index 0233ed5..d3ff293 100644
@@ -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))
Signature · 1 line
2.5.0
#1 lore raw

PATCH 1/1 Fix elf2flt build

Douglas,

Quoted 4 lines · Douglas RAILLARD

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

Signed-off-by Douglas RAILLARD <[email protected]>

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#2 lore raw

PATCH 1/1 Fix elf2flt build

Thomas,

Quoted 2 lines

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.

Quoted 1 line

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 ?

Quoted 2 lines

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 :

Quoted 20 lines

Douglas,

Quoted 4 lines · Douglas RAILLARD

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

Signed-off-by Douglas RAILLARD <[email protected]>

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

Signature · 1 line
Douglas RAILLARD

A message that is not in the archive (sent off-list or not yet received): 6966330.pLhB8QsgjT@raillard-dv6

#4 lore raw

PATCH 1/1 Fix elf2flt build

Douglas,

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

Quoted 7 lines · Douglas RAILLARD

Thomas,

Quoted 2 lines

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!

Quoted 2 lines

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.

Quoted 16 lines
Quoted 1 line

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.

Quoted 13 lines
Quoted 2 lines

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 ?

Quoted 3 lines

BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PTHREADS_NONE=y

Any reason to disable thread support?

Quoted 20 lines

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

Quoted 3 lines

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#5 lore raw

PATCH 1/1 Fix elf2flt build

Thomas,

Quoted 5 lines · 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!

Sorry, messed up with my mailer, previous email here for reference:
http://lists.busybox.net/pipermail/buildroot/2015-August/138057.html

Quoted 14 lines
Quoted 13 lines
Quoted 2 lines

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"

Quoted 3 lines

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

Quoted 5 lines
Quoted 3 lines

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

Quoted 4 lines

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

Signature · 1 line
Douglas RAILLARD
#6 lore raw

PATCH 1/1 Fix elf2flt build

Douglas,

Quoted 8 lines · Douglas RAILLARD
Quoted 3 lines

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.

Quoted 32 lines

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

Quoted 5 lines
Quoted 3 lines

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

Quoted 8 lines

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

Quoted 10 lines
Quoted 4 lines

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#7 lore raw

PATCH 1/1 Fix elf2flt build

Hi Douglas, Thomas,
Thomas Petazzoni wrote,

Quoted 13 lines

Douglas,

Quoted 8 lines · Douglas RAILLARD
Quoted 3 lines

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:

Quoted 14 lines

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.

Quoted 9 lines

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

Quoted 31 lines
Quoted 22 lines
Quoted 6 lines
Quoted 4 lines

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

Quoted 8 lines

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

Quoted 1 line

Another thing for Waldemar :-)

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

Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

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!

Quoted 7 lines
Quoted 5 lines

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

author
#8 lore raw

PATCH 1/1 Fix elf2flt build

Quoted 2 lines · Waldemar Brodkorb

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

Quoted 2 lines

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

Signature · 1 line
Douglas RAILLARD
#9 lore raw

PATCH 1/1 Fix elf2flt build

Hi,
Douglas RAILLARD wrote,

Quoted 27 lines · Waldemar Brodkorb
Quoted 2 lines

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

Quoted 2 lines

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

Quoted 7 lines

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

author
#10 lore raw

PATCH 1/1 Fix elf2flt build

Quoted 14 lines · Waldemar Brodkorb

Hi,
Douglas RAILLARD wrote,

Quoted 11 lines · Waldemar Brodkorb
Quoted 2 lines

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

Quoted 2 lines

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

Quoted 22 lines
Quoted 22 lines

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"
Quoted 6 lines
Quoted 1 line

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

Signature · 1 line
Douglas RAILLARD
#11 lore raw

PATCH 1/1 Fix elf2flt build

Douglas,

Quoted 2 lines · Douglas RAILLARD

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

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