Hello everybody,

CONFIG_EXAMPLES_MODULE and or CONFIG_EXAMPLES_ELF is enabled then
build fails (i.e. for tools/configure.sh lx_cpu:nsh) on my system.
I use Debian provided arm-none-eabi-gcc by default. The error reported:

-----------------------------------------------------------------------------------
make[5]: Entering 
directory '/home/pi/repo/nuttx/src/apps/examples/module/drivers/chardev'
MODULECC: chardev.c
arm-none-eabi-gcc -c -fno-builtin -Wall -Wstrict-prototypes -Wshadow -Wundef 
-Os -fno-strict-aliasing -fno-strength-reduce -fomit-frame-pointer 
-mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -isystem 
"/home/pi/repo/nuttx/src/nuttx/include" -D__NuttX__  -pipe -I 
"/home/pi/repo/nuttx/src/apps/include" -mlong-calls  -D__KERNEL__ 
chardev.c -o chardev.o
MODULELD: chardev.o
arm-none-eabi-gcc -r -e 
module_initialize -T /home/pi/repo/nuttx/src/nuttx/libs/libc/modlib/gnu-elf.ld  
-o 
chardev  chardev.o
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: error: 
chardev.o uses VFP register arguments, chardev does not
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: failed to 
merge target specific data of file chardev.o
collect2: error: ld returned 1 exit status
-----------------------------------------------------------------------------------

The cause is that LD has been changed to point to arm-none-eabi-gcc .
Use of GCC wrapper for the final image linking can probably help
with correct C++ libraries selection, possible link time optimizations
etc... But redefinition of LD symbol causes troubles when only
partial linking is required because GCC includes default libraries
even when -r relocatable output is required. Other problem is that
when GCC locates librares or even rebuilds machine code then same
set of arch flags should be specified, else mismatch of incompatible
codes is reported.

I have solved problem for LX_CPU by next change of flags used
for ELF loadable applications and modules

-----------------------------------------------------------------------------------
diff --git a/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs 
b/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
index de893534d8..fca2650e38 100644
--- a/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
+++ b/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
@@ -72,7 +72,7 @@ LDNXFLATFLAGS = -e main -s 2048
 CELFFLAGS = $(CFLAGS) -mlong-calls # --target1-abs
 CXXELFFLAGS = $(CXXFLAGS) -mlong-calls # --target1-abs

-LDELFFLAGS = -r -e main
+LDELFFLAGS = $(CELFFLAGS) -nostartfiles -nodefaultlibs -r -e main
 ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
   LDELFFLAGS += -T "${shell cygpath -w 
$(BOARD_DIR)$(DELIM)scripts$(DELIM)gnu-elf.ld}"
 else
@@ -83,7 +83,7 @@ endif

 CMODULEFLAGS = $(CFLAGS) -mlong-calls # --target1-abs

-LDMODULEFLAGS = -r -e module_initialize
+LDMODULEFLAGS = $(CMODULEFLAGS) -nostartfiles -nodefaultlibs -r -e 
module_initialize
 ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
   LDMODULEFLAGS += -T "${shell cygpath -w 
$(TOPDIR)/libs/libc/modlib/gnu-elf.ld}"
 else
-----------------------------------------------------------------------------------

I expect that same adjustment is required for many other targets.
I can prepare patch for our board only or for all where I find
same LDMODULEFLAGS and LDELFFLAGS pattern.

Other option is to return back to plain LD and define LINK or other
symbol for linker which would point to GCC wrapper. But such change
would require probably changes in the APPS and user projects
using NuttX with own APPS or with export support.

I have not updated my OMK builds to link separately compiled applications
with NuttX exported link kit with GCC wrapper. If the libraries
are collected by export, is it still necessary to use GCC wrapper?
Or was LTO, whole program optimization, automatic C++ templates
instances generaton reason to switch to linking through GCC?


Best wishes,

                Pavel

                Pavel Pisa

==================================================
 PiKRON s.r.o.       Phone/Fax: +420 284684676
 Kankovskeho 1235    Phone:     +420 234697622
 182 00 Praha 8      WWW:   http://www.pikron.com/
 Czech Republic      e-mail:  pik...@pikron.com
==================================================

Reply via email to