Hello Xiang Xiao, thanks for response.
On Sunday 18 of July 2021 13:13:50 Xiang Xiao wrote: > 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: ... > Thanks for reporting this issue. I am wondering why CI can't catch this > issue before the change merge. It is possible that none of the targets configuration used for CI enables CONFIG_EXAMPLES_MODULE and or CONFIG_EXAMPLES_ELF Or even when it enables them but architecture uses GCC default multilib then it can pass. Problem should demonstrate itself during linking (missing symbols required by NEWLIB libc and crt0) but it is possible that only for arm-none-eabi-not for *-nuttx-*. CONFIG_MODULE and or CONFIG_ELF alone allows to build end link NuttX but problems appears later when somebody tries use feature in own apps or own build against export. > > 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. The pull request draft, it would be great if checked by other boards maintainers as well https://github.com/apache/incubator-nuttx/pull/4173 > > 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 OK, I understand reasons to use GCC wrapper for linking, even for modules and ELF but I would prefer to define and use LINK variable to refer to linker and leave LD to point to real LD, because for some purposes, as conversion of tar images and other stuff into object files or for sother specific modifications of the object files it is much easier to use. But it is my preference and not strong one... But I would appreciate if there is deterministic mechanisms how to check if linking through GCC is used for given arch in exported Make.defs i.e. GCC_USED_FOR_LINKING=y. Our actual solution in pysimCoder is dirty hack ifneq ($(filter -Wl%, $(NXFLATLDFLAGS1)$(NXFLATLDFLAGS2)),) GCC_LD_OPTION = -Wl, endif I have hacked our OMK template to override LD for now to point to GNU ld https://github.com/ppisa/nuttx-devel/tree/master/nuttx-omk-template independently to NuttX export. I would reconsider the setup when NuttX is released or start to use LTO. The pysimCoder have been adapted to support both linking options by us about month ago https://github.com/robertobucher/pysimCoder/blob/master/CodeGen/templates/nuttx.tmf To support more smooth switch, I would be happy if LDSTARTGROUP LDENDGROUP are added correctly to exported Make.defs. But my actual nuttx-export-10.1.0-RC1/scripts/Make.defs shows LDENDGROUP = LDFLAGS = -nostartfiles -nodefaultlibs LDSTARTGROUP = I can try to investigate reason for empty values but export has been added by Abdelatif Guettouche so he can find problem faster or can have some opinion where is a problem. From the search, it seems that mips renesas risc-v x86_64 xtensa has not switched to linking by GCC.... so I hope I have not break something there. Best wishes, Pavel
