The PR removed the bulk of non-newlib headers from the NodeMCU source base.
app/libc has now been cut down to the bare minimum overrides to shadow the
corresponding functions in the SDK's libc. The old c_xyz.h headerfiles have been
nuked in favour of the standard <xyz.h> headers, with a few exceptions over in
sdk-overrides. Again, shipping a libc.a without headers is a terrible thing to do. We're
still living on a prayer that libc was configured the same was as a default-configured
xtensa gcc toolchain assumes it is. That part I cannot do anything about, unfortunately,
but it's no worse than it has been before.
This enables our source files to compile successfully using the standard header files,
and use the typical malloc()/calloc()/realloc()/free(), the strwhatever()s and
memwhatever()s. These end up, through macro and linker magic, mapped to the
appropriate SDK or ROM functions.
When lua assertions are enabled, normal operation results in many:
lobject.c:88: (((t1)->tt) == 4)
lobject.c:88: (((t2)->tt) == 4)
lobject.c:88: (((t1)->tt) == 4)
lobject.c:88: (((t2)->tt) == 4)
lobject.c:88: (((t1)->tt) == 4)
lobject.c:88: (((t2)->tt) == 4)
It comes from using the pvalue() macro for 3 pointer types, where
pvalue() also checks the type of pointer and complains through the
assertion where the type == 4 (TLIGHTUSERDATA).
Use the correct macro according to the type of data being compared
to eliminate this assertion error.
Signed-off-by: Nick Andrew <nick@nick-andrew.net>
plus Add extra logic to handle different loci path in luac.cross
for handling 32 bit or great hex integers Also add a helpfull hint in the
build tool to point out the Lua and lfs depencencies.
Johny Mattsson
sergio
TerryE
Nick Andrew
funshine
HuangRui