-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zephyr Native Posix Build Uses Linux Build Machine Headers out of Sandbox #35813
Comments
Also have collision on Linux header for select.h. In file included from /usr/include/x86_64-linux-gnu/sys/select.h:30, |
I am not positive what the proper behavior is for NATIVE POSIX development. I looks like gcc in the output logs matches the gcc version on my Linux machine. Perhaps with that, it is using the default include paths prior to the Zephyr ones. By contrast, should one expect that an X86 cross compilation should occur? Should I change my environment/system configuration to prevent these default include files from being part of the build process? Is there any ordering of the project include files (including stdio, stdint) that could be tripping this up? The full compile output is as follows: west build: making build dir /home/robocom/RCSUS/ddltconfig/build pristine warning: POSIX_API (defined at lib/posix/Kconfig:12) was assigned the value 'y' but got the value warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but warning: The choice symbol NEWLIB_LIBC (defined at lib/libc/Kconfig:27) was selected (set =y), but -- The C compiler identification is GNU 9.3.0 [140/147] Building CXX object CMakeFiles/app.dir/src/config/sessionConfig.cpp.obj |
Here is the project kernel configuration as a ZIP compressed file. |
Hi @bob2oneil As extra info naive_posix does use your host default gcc and libC. That is as intended by design. If this answers your question, feel free to close the issue. |
Thanks for the quick attention to this issue. I explicitly set the project configuration with CONFIG_POSIX_API=n, and the problem still remains. I still see Linux header files included in the Native Posix build. The following are some updates to both the kernel configuration and the output. Any other ideas? CONFIG_CPLUSPLUS=y `robocom@scnuc-1:~/SUS/ddltconfig$ west build -p always -b native_posix_64 ./ warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but warning: The choice symbol NEWLIB_LIBC (defined at lib/libc/Kconfig:27) was selected (set =y), but Parsing /home/robocom/SUS/ddltconfig/Kconfig [96/166] Building CXX object CMakeFiles/app.dir/src/config/sessionConfig.cpp.obj |
That is meant to happen. You cannot set By the way, you can use triple back ticks |
No reason on NEWLIB other than to ensure that I can build for both QEMU and Native Posix, presumably using the same project files .. that in generally being new to Zephyr. Thanks for the tips. I have tried again with NEWLIB set to external, but have the same build issues. I am to understand that perhaps different kernel configs are required for different board targets? When targeting posix, should I not be including #include <net/socket.h>, and just use I was thinking that all of the native Linux platform stuff would be sandboxed, so only content |
""" warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but -- The C compiler identification is GNU 9.3.0 [146/166] Building CXX object CMakeFiles/app.dir/src/config/sessionConfig.cpp.obj |
That is not uncommon. You can set kconfig overlays for each board you want to treat differently. (you can find some examples of that in the tree, just look for samples with a folder with a board name, with some kconfig and/or dts overlays in them)
@jukkar are you able to help @bob2oneil ? Does he need to disable NET_SOCKETS_POSIX_NAMES and probably more in native_posix?
I doubt that would work..
Not really. You are building with the host libC. So name clashes are unfortunately easy to encounter. |
@bob2oneil like this: (tripple back ticks == the backwards accent character)
|
Thanks, I will correct all future back ticks properly. What do you recommend now for creating native POSIX socket applications running under Zephyr. I am looking for BSD sockets, Linux poll() and select(), promiscuous sockets, runtime settable IP and MTUS, one real Ethernet interface (kernel configured) and one virtual Ethernet (9K MTU). I want to build a bridge applications IPv4 between 2 interfaces. I am ok with different kernel configurations for different board targets |
The networking sample applications are compiled all the time with native_posix and there is no need to disable
|
I am able to build the sample application without any event. However, my application has a bunch more C++ class, uses some standard C/C++ headers, and I wonder if somehow "types.h" gets included or other platform headers that is causing the havoc. I will do a strip down to see if this improves anything. Would one of you fine gentleman be willing to test out my project to see if at least we are experiencing the same build issues? I could ZIP and send in a private email. I will post anything I find from my strip of standard header operations. Hopefully this work will be of benefit to the broader Zephyr community. |
Thanks for the quick responses. Attached is the current build issues as I strip away as much of the standard headers as possible. Is there any advanced west argument that would provide more information on the include search paths, and what caused a certain standard header to be included? For example, the errors occur as a function of including standard header "types.h", which are not directly included in the source code. /usr/include/x86_64-linux-gnu/sys/types.h:179 -- The C compiler identification is GNU 9.3.0 [160/167] Building CXX object CMakeFiles/app.dir/src/config/sessionConfig.cpp.obj |
The referenced collision in types.h is the inclusion of sys/select with collides with the Zephyr implementation even with CONFIG_POSIX_API=n
|
|
Additional testing needs to be performed, but I was finally able to get this sample project to build under Native Posix 64 by changing the order of the entries in the project kernel configuration. This might make some sense, or perhaps this change was anecdotal, and simply caused some other unexplained benefit. I was building within west using the "-p always" flag to presumably sweep away and previous build artifacts and I deleted the entire 'build' subfolder a few times. My working prj.conf is as follows. Perhaps this explanation rings a bell for you Zephyr experts that have generously commented on my postings. I hope this will be of some benefit to other users that may have experienced the same behaviors for Native POSIX builds with collisions with Linux file system headers.
|
Unfortunately that is a bad use case for native_posix.
Nice to hear. I guess we can close this issue/question by now then(?) (it can be always reopened if needed) |
My thanks to aescolar and jukkar for helping out on this topic in a quick manner. You guys are a credit to the open source community. |
I am creating a network enabled application, and my build targets are both native_posix_64 and qemu_riscv64. I am able to compile for the QEMU board target.
However, for the native_posix_64 built, I get collisions with headers that are defined on my native Linux build machine rather than what I assumed was a cross compiled "sandbox", where for native POSIX, the cross compilation would not use anything native to my Linux distro, but entirely Zephyr alone.
As such, I am unable to compile properly as there is a mixture of Zephyr and native Linux.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clean build within any errors and inclusion of native Linux build machine headers.
Impact
Showstopper
Logs and console output
Environment (please complete the following information):
Additional context
This is the inclusion of the native include header is troublesome:
from /usr/include/x86_64-linux-gnu/sys/types.h:179,
Project Configuration is as follows:
My default gcc include paths are as follows:
The text was updated successfully, but these errors were encountered: