-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
64 bit print format specifiers not defined with newlib and SDK 0.10.0 #14310
Labels
area: Toolchains
Toolchains
bug
The issue is a bug, or the PR is fixing a bug
priority: medium
Medium impact/importance bug
Comments
@SteveOss fyi |
galak
added a commit
to galak/zephyr
that referenced
this issue
Mar 13, 2019
When we build with newlib we don't set -nostdinc. In that case make sure that we leave it to the toolchain to set the system include paths. The one exception to leaving to the toolchain to set the system include paths is the path to the newlib headers. Since we build with -ffreestanding we need to make sure the newlib header path is the before the toolchain headers. Otherwise the toolchain's 'freestanding' headers get picked up and that causes issues (for example getting PRI*64 defined properly from inttypes.h due to __STDC_HOSTED__ being '0'). For newlib we accomplish this by having the only system header specified by zephyr_system_include_directories() being just the newlib headers. Note: for minlibc we leave things alone as things just happen to work as the -I include of the libc headers takes precedence over -isystem so we get the libc headers over the toolchain ones. For the newlib case it appears that setting both -I and -isystem for the same dir causes the -I to be ignored. Fixes zephyrproject-rtos#14310 Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
galak
added a commit
that referenced
this issue
Mar 13, 2019
When we build with newlib we don't set -nostdinc. In that case make sure that we leave it to the toolchain to set the system include paths. The one exception to leaving to the toolchain to set the system include paths is the path to the newlib headers. Since we build with -ffreestanding we need to make sure the newlib header path is the before the toolchain headers. Otherwise the toolchain's 'freestanding' headers get picked up and that causes issues (for example getting PRI*64 defined properly from inttypes.h due to __STDC_HOSTED__ being '0'). For newlib we accomplish this by having the only system header specified by zephyr_system_include_directories() being just the newlib headers. Note: for minlibc we leave things alone as things just happen to work as the -I include of the libc headers takes precedence over -isystem so we get the libc headers over the toolchain ones. For the newlib case it appears that setting both -I and -isystem for the same dir causes the -I to be ignored. Fixes #14310 Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area: Toolchains
Toolchains
bug
The issue is a bug, or the PR is fixing a bug
priority: medium
Medium impact/importance bug
if building with
CONFIG_NEWLIB_LIBC=y
and SDK 0.10.0 this fails.Reported as an issue on SDK-NG:
zephyrproject-rtos/sdk-ng#55
But after some investigation this is related to how we invoke gcc in Zephyr, and not the SDK itself.
The text was updated successfully, but these errors were encountered: