Makefile: Newlib: Added pattern to NEWLIB_INCLUDE_PATTERN #5131
Conversation
OlegHahm
added
Area: build system
| NEWLIB_INCLUDE_PATTERNS ?= \ | ||
| /etc/alternatives/gcc-$(TARGET_ARCH)-include \ | ||
| /usr/$(TARGET_ARCH)/include \ | ||
| /usr/local/opt/$(TARGET_ARCH)*/$(TARGET_ARCH)/include \ | ||
| /usr/local/opt/gcc-arm/$(TARGET_ARCH)/include \ |
There was a problem hiding this comment.
Probably this pattern is not only used for ARM, so how about gcc-* instead of gcc-arm?
There was a problem hiding this comment.
Yes, you're right.
I will commit again.
Thanks
cgundogan
added
the
CI: needs squashing
|
@kYc0o can you also verify this on your OSX machine? |
|
I didn't experienced the same problem and my $PATH for my toolchain is set differently. For some reason my machine is able to find newlib without this change... Anyways, I don't think it's a good idea to put all "possible" paths on this file and if it's not found to throw a compilation error without any insights. @cgundogan your toolchain's path coincide with one of those that appear on the file? |
|
Hi again I think this is not happening on every OS X. It seems it's not a typical PATH. For me this started to happen in commit 2b51e4b With the older version of this file, my NEWLIB_INCLUDES variable is blank. With the current version, NEWLIB_INCLUDES is "-isystem /nano -isystem", so INCLUDES variable is: -isystem /nano -isystem -I/Users/jia200x/Development/RIOT/core/include ..._ The second -isystem causes the crash, for testing I tried to set NEWLIB_INCLUDES variable to "-isystem /nano" and compiles without problems. I think one way to fix this could be to add something like: Does it seem reasonable? Also, I noticed my compile process was not including newlib header files. Are they mandatory for RIOT? |
|
@jia200x can you squash the commits? The change looks sane and it should not break the previous behaviour. So I'd say ACK |
jia200x
force-pushed
the
newlib_makefile_fix
branch
from
c09665a
to
808803e
Compare
|
Squashed. Thank you. Cheers! |
cgundogan
added
CI: ready for build
|
@kYc0o I don't think that we will fill up the include path with many different possible paths. I can imagine that different installation procedures will reflect differently on the filesystem. The same could happen due to a different version of OSX, or maybe because the maintainer of the gcc-arm package (I assume such a thing exists on OSX) has decided to change the path. As long as nobody adds a path to a user defined directoty ( |
| @@ -28,11 +28,12 @@ export LINKFLAGS += -lc -lnosys | |||
| # Ubuntu seem to put a copy of the newlib headers in the same place as | |||
| # Gentoo crossdev, but we prefer to look at /etc/alternatives first. | |||
| # On OSX, newlib includes are possibly located in | |||
| # /usr/local/opt/arm-none-eabi*/arm-none-eabi/include | |||
| # /usr/local/opt/arm-none-eabi*/arm-none-eabi/include or /local/opt/gcc-arm/arm-none-eabi/include | |||
|
@cgundogan agree. |
jia200x
force-pushed
the
newlib_makefile_fix
branch
from
808803e
to
36a7d29
Compare
|
Oops. Just fixed. |
cgundogan
added
the
Type: bug
|
Cool! |
Hi
Some arm toolchains in OSX are installed in /usr/local/opt/gcc-arm/$TARGET_ARCH
When the current Makefile tries to search for the location of include files, it doesn't find them and the variable NEWLIB_INCLUDE_DIR is blank.
In the end, this produces errors like:
_Building application "default" for "samr21-xpro" with MCU "samd21".
/Users/jia200x/Development/RIOT/examples/default/main.c:28:20: fatal error: thread.h: No such file or directory
#include "thread.h"
^
compilation terminated.
make[1]: *** [/Users/jia200x/Development/RIOT/examples/default/bin/samr21-xpro/default/main.o] Error 1
make: *** [all] Error 2_
I added the /usr/local/opt/gcc-arm/$TARGET_ARCH pattern to Makefile.
Also, do you think there should be an error message or something if newlib dirs are not found?
Best regards