On Sat, Jul 17, 2021 at 4:10 PM Pavel Pisa <ppisa4li...@pikron.com> wrote:
> 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.
>
>
Thanks for reporting this issue. I am wondering why CI can't catch this
issue before the change merge.
> 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.
>
>
It will be great if you can fix the problem for other boards too, thanks.
> 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?
>
>
Please see the discussion here:
https://github.com/apache/incubator-nuttx/pull/3836
https://github.com/apache/incubator-nuttx/pull/3900
> 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
> ==================================================
>
