Re: devel/arm-none-eabi-newlib headers inconsistencies (not functional) or am I misusing something?
- Reply: José_Pérez : "Re: devel/arm-none-eabi-newlib headers inconsistencies (not functional) or am I misusing something?"
- In reply to: Mark Millard : "Re: devel/arm-none-eabi-newlib headers inconsistencies (not functional) or am I misusing something?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 27 May 2023 13:21:42 UTC
On May 27, 2023, at 05:27, Mark Millard <marklmi@yahoo.com> wrote: > On May 27, 2023, at 04:21, José Pérez <fbl@aoek.com> wrote: > >> El 2023-05-27 12:18, Mark Millard escribió: >>>> should be fixed or is it ok >>>> to leave it as it is now? >>> Leave it as it is. >> >> Ok. >> >>> You need >>> /usr/local/lib/gcc/arm-none-eabi to be first (or >>> the only entry). >> >> If I force the search path to use /usr/local/arm-none-eabi/include >> only, it does not work: >> % arm-none-eabi-gcc -nostdinc -I/usr/local/arm-none-eabi/include break_arm.c >> In file included from /usr/local/arm-none-eabi/include/stdio.h:35, >> from break_arm.c:1: >> /usr/local/arm-none-eabi/include/sys/cdefs.h:45:10: fatal error: stddef.h: No such file or directory >> 45 | #include <stddef.h> >> | ^~~~~~~~~~ >> compilation terminated. > > Interesting that devel/arm-none-eabi-newlib would be > incomplete in its file coverage. But its use of > stddef.h from gcc is probably just fine (for now). > (Language standard update tracking could change > that someday if material that is used is moved > between headers by the standard.) > >> If I add arm gcc port paths AFTER newlib path, it works: >> % arm-none-eabi-gcc -nostdinc -I/usr/local/arm-none-eabi/include -I/usr/local/lib/gcc/arm-none-eabi/11.3.0/include -I/usr/local/lib/gcc/arm-none-eabi/11.3.0/include-fixed -c break_arm.c It is unclear what you are doing for linking. I expect for the link to be using the devel/arm-none-eabi-newlib files for linking, that you would need to use -nodefaultlibs and other command line options to control which files are used for linking, much like for the headers. This might involve using, say, -Wl,??? options to control the linker more directly. Using -v on the arm-none-eabi-gcc command lines should show more detail about what the compiler is doing for its various stages, including linking if you use arm-none-eabi-gcc to cause the linking. >> && echo done >> done >> >> Shall the include path be swapped in the arm gcc port? > > No. Ports like sysutils/u-boot-rpi2 would end up using > devel/arm-none-eabi-newlib when it happens to be installed > -- but should not use devel/arm-none-eabi-newlib. The order > is correct for the 30+ ports that use devel/arm-none-eabi-gcc > already. You should not change what happens for those ports. > >> We shall also evaluate whether the system defaul /usr/include shall >> be left as a last resort or not. > > This removal might be valid, I do not know. None of > the ports that use devel/arm-none-eabi-gcc should > actually find or use any files from the /usr/include/ > tree. If some purpose needed /usr/include/ , it could > use the command line to get the search path it needs. > === Mark Millard marklmi at yahoo.com