Export Make.defs broken, missing HEAD_OBJ, LDENDGROUP, LDSTARTGROUP

[ppisa]

From the e-mail reported on 2021-07-19

NuttX export cannot set some variables (i.e. LDSTARTGROUP LDENDGROUP)

I have found cause for broken/empty LDENDGROUP and LDSTARTGROUP in exported Make.defs

nuttx-export-10.1.0-RC1/scripts/Make.defs

as

HEAD_OBJ         = 
LDENDGROUP       =
LDFLAGS          = -nostartfiles -nodefaultlibs
LDSTARTGROUP     =

The reason is that

tools/mkexport.sh

invokes

${MAKE} -C "${TOPDIR}/tools" -f Makefile.export TOPDIR="${TOPDIR}"

tools/Makefile.export includes

include $(TOPDIR)/.config
include $(EXPORTDIR)/Make.defs

and generates temporary ${EXPORTDIR}/makeinfo.sh

But LDENDGROUP and LDSTARTGROUP are defined in

arch/{avr,hc,mips,misoc,or1k,renesas,risc-v,sim,x86,x86_64,xtensa}/src/Makefile

which are not sourced by tools/Makefile.export.

Only exception is arch/arm/src/rtl8720c/Toolchain.defs which could probably work.

The question is if to try to source complete Makefile by export (probably would lead to other problems) or to change how architectures defines these options for toolchain.

It can take more time to solve this problem clean way. May it be it solves if build system is switched. I would prefer meson + ninja above cmake or stay with GNU make, but cmake support is one of the most robust options today.

As for temporal workaround I suggest to define some flag in each Make.defs setting LD=*-gcc to indicate that

LINK_IS_DONE_BY_CC=y

Or may it be set it in arch Kconfig then it can be used even during configuration or can be configurable, which would do probably more harm than proffit.

Actual state is that LDENDGROUP and LDSTARTGROUP must not be used in builds using exported Make.defs directly. Use requires check that they are empty and workaround as has been hacked into pysimCoder NuttX template nuttx.tmf.

Missing HEAD_OBJ is worse because it cannot be guessed easily by the pysimCoder or OMK build which are using NuttX export.

Best wishes,

Pavel

[jerpelea]

@ppisa do you have any progress on this report?

I would like to add the fix to the 10.3 release if it comes in time

Thanks Alin

[ppisa]

Hello, I have found time only now and test state with actual NuttX sources.

I test with tools/configure.sh esp32c3-devkit:twai but it seems to be problem with most other architectures.

When I run make export then at least HEAD_OBJ is not exported.

it is initially defined in nuttx/arch/risc-v/src/esp32c3/Make.defs:

HEAD_ASRC = esp32c3_head.S

It then used in nuttx/arch/risc-v/src/Makefile:

HEAD_OBJ = $(HEAD_ASRC:.S=$(OBJEXT))
STARTUP_OBJS ?= $(HEAD_OBJ)

nuttx/tools/mkexport.sh:

  echo "HEAD_OBJ         = ${HEAD_OBJ}" >>"${EXPORTDIR}/scripts/Make.defs"

then nuttx-export-10.3.0/scripts/Make.defs:

HEAD_OBJ         =

Same problem with LDENDGROUP and LDSTARTGROUP

nuttx/tools/Export.mk does not include HEAD_OBJ but it includes LDENDGROUP and LDSTARTGROUP which are not exported as well. Even when I add line for HEAD_OBJ it does not help.

nuttx/tools/Export.mk includes only.

include $(TOPDIR)/.config
include $(EXPORTDIR)/Make.defs

The second one is copy of ${TOPDIR}/Make.defs which is link to risc-v/esp32c3/esp32c3-devkit/scripts/Make.defs.

It includes

include $(TOPDIR)/.config
include $(TOPDIR)/tools/Config.mk
include $(TOPDIR)/tools/esp32c3/Config.mk
include $(TOPDIR)/arch/risc-v/src/common/Toolchain.defs

But none of these includes group and or head information.

This is only included in nuttx/arch/risc-v/src/Makefile but that cannot be sourced, because it defines too many rules and is not probably prepared for to be used as source of defines for other Makefiles.

So I think that LDSTARTGROUP and LDENDGROUP should be defined in nuttx/arch/risc-v/src/common/Toolchain.defs. There should be even explicit define LINK_BY_CC or LINK_BY_LD to select if link is done by CC or LD. Where should be moved define HEAD_ASRC and preparation of HEAD_OBJ is even more questionable. It wold be ideal to do the change for all architectures and boards...

[acassis]

@ppisa maybe we need to open an issue to get library support for CMakefiles too!