Before the build system used something like
echo "int main(){} void _exit(int n) {(void)n;while(1);}" | LC_ALL=C $(LINK) -xc - -o /dev/null -lc -Wall -Wextra -pedantic <FLAGS_TO_TEST>
to check for flags supported by the compiler (used as linker frontend).
This however no longer works with newlib 4.3.0, which requires the
symbols `_sbrk_r`, `_close_r`, `_lseek_r`, `_read_r`, and `_write_r` to
be present. Instead, now a new file `minimal_linkable.c` was added that
adds all the missing symbols and is used in the linker feature tests
instead.
The test for the requirement of disabling wchar_t size warnings assumed
that $(CC) is used for linking, instead of $(LINK). With GCC $(LINK)
and $(CC) happen to be (in most cases) identical, but with LLVM they
are not. This results in issues with compiling with LLVM.
The check for `newlib-nano` assumes that a toolchain which provides `newlib-nano` provides both the normal version and the nano version of the `newlib`.The nano version of `newlib.h` is therefore stored in its own include directory. This is the case for toolchains which allow to use both the normal and the nano version, e.g. for ARM and RISC-V.
However, if the toolchain provides `newlib_nano` but only allows the use of the nano version, it will only have the nano version of `newlib.h` and no separate directory for it, e.g. for ESP32.
To still be able to use such toolchains with `newlib_nano`, the check is changed so that the setting of the `-isystem` option depends on the existence of the separate directory.
It replaces
make BOARD=iotlab-m3 info-debug-variable-NEWLIB_INCLUDE_DIR
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/
with
make BOARD=iotlab-m3 info-debug-variable-NEWLIB_INCLUDE_DIR
/usr/arm-none-eabi/include
Without trailing slash and without relative '..' everywhere.
It also uses `realpath` instead of `abspath` to support Mingw32.
Some versions of Mingw32 abspath implementation has trouble working with
windows formatted path.
$(abspath "C:/A/B") returns "/C/CUR/DIR/C:/A/B" instead of "/C/A/B"
relpath does not have this problem, it does additional symlink resolution but is
not a problem.
Note: on windows it does not remove the trailing `/`.
https://github.com/zephyrproject-rtos/zephyr/issues/2061#issuecomment-331635063
Patched in
941059c69f
Only keep lines that are indeed include path.
It also keeps newlines as they do not matter.
It fixes Mingw32 support where `grep '^\s'` is not working the same way.
It also handles some mac `sed` that do not support `\s`.
Ouput tested with:
make -C examples/hello-world BOARD=samr21-xpro info-debug-variable-COMPILER_INCLUDE_PATHS
# by also putting newlines for readability
Now:
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include-fixed
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include
Before:
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/cc1 -E -quiet -v -iprefix /usr/bin/../lib/gcc/arm-none-eabi/7.2.1/ -isysroot /usr/bin/../arm-none-eabi -D__USES_INITFINI__ /dev/null
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include-fixed
/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include
When NEWLIB_INCLUDE_DIR is set from other parts than 'COMPILER_INCLUDE_PATHS' it
does not have a trailing slash.
Also, it makes it more problematic when supplying it from the command line.
And anyway having two '/' does not break anything.
In the previous state, with llvm and arm for example, newlib-nano include dir
NEWLIB_NANO_INCLUDE_DIR is placed after NEWLIB_INCLUDES and so the default
'newlib.h' is used instead of the nano version.
