Re: devel/arm-none-eabi-newlib headers inconsistencies (not functional) or am I misusing something?

On May 27, 2023, at 05:27, Mark Millard <[email protected]> wrote:

> On May 27, 2023, at 04:21, José Pérez <[email protected]> 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