Yes - I have CONFIG_NSH_CLE defined.

There are no .o files after a make clean

>-----Original Message-----
>From: Nathan Hartman <hartman.nat...@gmail.com>
>Sent: 17 August 2022 19:10
>To: dev@nuttx.apache.org
>Subject: Re: 10.3 merge issues
>
>On Wed, Aug 17, 2022 at 12:56 PM TimH <t...@jti.uk.com> wrote:
>> 1.      Final change that allowed a compile was when I changed the defconfig
>> to have the new:
>>
>>
>>
>> CONFIG_INIT_ENTRYPOINT="nsh_main"
>>
>> CONFIG_INIT_ENTRYNAME="nsh"
>>
>>
>>
>> It all boots and I get the nsh prompt but I get continuous:
>>
>>
>>
>> nsh_session: cle failed: 22
>>
>>
>>
>> I'm assuming that's EINVAL, but I can't work out why?
>
>
>Looks to me like this message is probably printed from nsh_stdlogin(), but I
>cannot understand where the "nsh_session" part of that printout is coming
>from. Do you have CONFIG_NSH_CLE defined? (NSH_CLE in Kconfig).
>
>More below...
>
>
>> 2.      my board Make.defs file is an edited clone of another from the same
>> device (SAMA5D2) and is virtually identical to many other similar
>> files for other chips of course. I am running "Ubuntu 20.04.3 TLS"
>>
>> This is included in virtually all these files for any chip/arch:
>>
>> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
>>
>>   ARCHSCRIPT = -T "${shell cygpath -w
>> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
>>
>> else
>>
>>   ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>>
>> endif
>>
>> But the compiler complains that there's:
>>
>> no rule to make target  '-T/home/{rest of the path}'
>>
>> If I remove the -T it is fine.
>>
>> Linux/Ubuntu is including the -T in the path I assume? Seems very odd
>> that
>> 10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume?
>> Linux skills are definitely lacking, so any suggestions welcomed!
>
>
>Regarding question #2:
>
>Dumb question, but after 'make clean' or 'make distclean' could you verify
>there are no stale object files (*.o) anywhere in the nuttx or apps trees? I'm
>asking because I've run into this problem in the past where some obscure
>error in the makefiles caused some stale objects to stay around.
>
>Cheers,
>Nathan

Reply via email to