On ESP32 and new ESP8266 platform, the compilation of the package fails since a local variable is potentially used uninitialized. Therefore, the variable is initialized with a default value.
I basically didn't work on `emb6` since 2016 and adapting to the newest
version would mean some major overhaul. However, the development at
their end seems to be stalled [since March 2018][emb6-develop] as well.
All this speaks for deprecating this package.
[emb6-develop]: https://github.com/hso-esk/emb6/tree/develop
export COMP by using the environment insteal of through the shell to
prevnet issues with `\"` being defined when keeping macros in CFLAGS.
Another solution was to use COMP='...' but could there could still have
issues with single quotes in CFLAGS.
The correct way to overrride the malloc family of functions in newlib-nano is
to provide the *_r (reentrant) variants. Newlib implements the "normal"
functions on top of these (see the newlib source code). Also, internally it calls
the *_r functions when allocating buffers.
If only the "normal" non-reentrant functions are provided this will mean that
some of the code will still use the vanilla newlib allocator. Furthermore, if
one uses the whole heap as a pool for TLSF then the system may in the best case
crash as there is no enough memory for its internall allocations or in the worst
case function eratically (this depends on how the heap reserved, there is an
upcomming series of commits in that direction).
This commit splits the handling between newlib and native. It also prepares the
ground for future work on the pool initialization.
Right now I could only test this in ARM and native and I cannot ensure it will
work on other platforms. Replacing the system's memory allocator is not something
that can be taken lightly and will inevitably require diving into the depths of
the libc. Therefore I would say that using TLSF as a system wide allocator is ATM
supported officially only on those plaftorms.
Testing:
Aside from reading the newlib sources, you can see the issue in a live system
using the debugger.
Compile any example (with or without tlsf-malloc), grab a debugger and place
a breakpoint in sbrk and _sbrk_r. Doing a backtrace will reveal it gets called
by _malloc_r.
