Application compiled with CONFIG_POSIX_API doesn't have access to POSIX headers

[pfalcon]

Turns out, when an application (e.g. a sample) has an option CONFIG_POSIX_API=y in its prj.conf, it doesn't have include/posix/ path added to its compiler include path. This is completely unexpected given the https://github.com/zephyrproject-rtos/zephyr/blob/master/lib/posix/CMakeLists.txt#L6 directive. Turns out that a few POSIX tests we have work that around by explicitly adding that include path explicitly in app's CMakeLists.txt: https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/posix/common/CMakeLists.txt#L7

This is completely not adequate behavior, requiring obscure options to use Zephyr POSIX subsystem, and leaking and repeating details of internal setup into each and every POSIX app.

[pfalcon]

The effect of this is as follows: when POSIX subsystem implementation files are built, they are using include/posix/. Later, when an application is built, those headers are not available, and libc headers are picked up instead. In case of newlib, that means that different definitions for various types and structures are used, leading to erratic behavior of apps. In case of minlibc, it means that almost any, even trivial, POSIX app won't build, as header set for minlibc is very minimal.

Overall, this exposes yet another level of header conflict of POSIX subsystem with everything else.

@galak, FYI, this is one of major issues with POSIX subsys in Zephyr.

[pfalcon]

@SebastianBoe, please help to fix this issue.

[SebastianBoe]

This should be resolved by turning PTHREAD into a zephyr_interface_library.

There are many examples of this in-repo that can be used as a reference.

[pfalcon]

This should be resolved by turning PTHREAD into a zephyr_interface_library.
There are many examples of this in-repo that can be used as a reference.

Thanks for prompt reply @SebastianBoe, and sorry that it took some time on my side to play well with it. And while initially (with my own examples) it seemed to work, a more detailed look and trying to convert existing tests showed that it actually doesn't.

As you say, there're a few users of "zephyr_interface_library_named" directive (there doesn't seem to be "zephyr_interface_library" directive). Specifically, subsys/fs, lib/gui/lvgl, ext/lib/mgmt/mcumgr, ext/lib/crypto/mbedtls. I posted my attempt on conversion at #15937. It's pretty simple actually - just replaced add_library with zephyr_interface_library_named. I checked that all other directives look pretty much the same as for lib/gui/lvgl and ext/lib/crypto/mbedtls (these 2 are good examples, as they use target_include_directories, just as needed for the posix subsys). Unfortunately, as #15937 shows, an app can't find the headers after wards. Tracing the build commands, invocation of gcc for sample's main.c simply doesn't have needed -I directives, while for an ext/lib/crypto/mbedtls sample, the expected -I directives for its headers are there.

I really can't see any difference with mbedtls/lvgl setup, and have no idea what may be wrong. @SebastianBoe, can you please have a look?