posix: Recently enabled POSIX+newlib tests fail to build with gnuarmemb

[pfalcon]

With c894aa3 landing, we see failures in these POSIX+newlib tests built using ARM GCC embedded toolchain (gnuarmemb) in our (Linaro's) CI: https://ci.linaro.org/job/zephyr-upstream/PLATFORM=frdm_k64f,ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb,label=docker-xenial-amd64-13/3584/console

Specific failure is:

01:46:54 make[3]: Entering directory `/home/buildslave/srv/zephyr/master/gnuarmemb/frdm_k64f/frdm_k64f/tests/posix/fs/portability.posix.newlib'
01:46:54 [ 80%] Building C object zephyr/CMakeFiles/priv_stacks_prebuilt.dir/misc/empty_file.c.obj
01:46:54 [ 81%] Linking C executable priv_stacks_prebuilt.elf
01:46:54 /home/buildslave/srv/toolchain/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7e-m/libc.a(lib_a-writer.o): In function `_write_r':
01:46:54 writer.c:(.text._write_r+0x12): undefined reference to `_write'
01:46:54 /home/buildslave/srv/toolchain/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7e-m/libc.a(lib_a-closer.o): In function `_close_r':
01:46:54 closer.c:(.text._close_r+0xc): undefined reference to `_close'
01:46:54 /home/buildslave/srv/toolchain/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7e-m/libc.a(lib_a-lseekr.o): In function `_lseek_r':
01:46:54 lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
01:46:54 /home/buildslave/srv/toolchain/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7e-m/libc.a(lib_a-readr.o): In function `_read_r':
01:46:54 readr.c:(.text._read_r+0x12): undefined reference to `_read'
01:46:54 collect2: error: ld returned 1 exit status

As Linaro is committed to support Zephyr buildability with gnuarmemb, I'm going to look into that.

[pfalcon]

@galak: FYI

[pfalcon]

First thing to see if it's a recent regression, or it was like that always, we just exposed that with recent enabling of POSIX+newlib builds. So, I did git co @{"1 month ago"} (which landed at 5c23843), and after patching a number of header conflicts (so, we actually improved since then), I get the same failure:

/home/pfalcon/toolchain/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7e-m/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x12): undefined reference to `_write'
/home/pfalcon/toolchain/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7e-m/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
/home/pfalcon/toolchain/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7e-m/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
/home/pfalcon/toolchain/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/lib/thumb/v7e-m/libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text._read_r+0x12): undefined reference to `_read'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/priv_stacks_prebuilt.dir/build.make:100: recipe for target 'zephyr/priv_stacks_prebuilt.elf' failed

So, it's not new, and I'll be investigating ways to deal with it.

[galak]

So I think we might need to expose FUNC_ALIAS(_lseek, lseek, int) more broadly in lib/libc/newlib/libc-hooks.c.

[pfalcon]

So I think we might need to expose FUNC_ALIAS(_lseek, lseek, int) more broadly in lib/libc/newlib/libc-hooks.c.

Yes, except stuff there are stubs to be used as a fallback when no real POSIX funcs are there. We perhaps can factor out FUNC_ALIAS'es to a common place, but the the question which is the primary - read() or _read(). IIRC, from viewpoint of newlib, _read is a syscall, whereas read() is libc function. Which is subtle distinction we already discussed with @andrewboie on planning to add syscall for POSIX unistd part, and agreed, that for us, the syscall would be called sys_read. Bottom line: no matter what would be done now, it would need to be redone later when the actual syscalls are implemented. Then just let me propose the easiest and smallest by delta solution: #13940