Issue with RTEMS 4.12 compiler include path

[Chris Johns]

On 23/06/2016 04:39, John Harwell wrote:
> The command line make uses when attempting to compile my super-simple test application is:
>
> /opt/rtems-4.12/bin/sparc-rtems4.12-gcc -O0 -g -D__rtems__ -m32 -W -Wall -Wextra -std=gnu99 -fmessage-length=0 -isystem/opt/rtems-4.12/lib/gcc/sparc-rtems4.12/6.1.1/include -isystem/opt/rtems-4.12/lib/gcc/sparc-rtems4.12/6.1.1/include-fixed -isystem/opt/rtems-4.12/lib/gcc/sparc-rtems4.12/6.1.1/../../../../sparc-rtems4.12/include ./tests/spw-test.c  -o bin/spw-test  -lm
  [snip]
> However, if I add -I/opt/rtems-4.12/sparc-rtems4.12/leon3/lib/include to
> the command line (the location of rtems.h), then everything works fine.
> My understanding is that this is a "system" include directory that
> should be one of the default paths searched by the compiler.

Your understanding is correct.

Why does RTEMS not automatically support including a "system" include 
directory? This is a reasonable question and worth discussing in detail.

I can see from the path to the compiler you have built the tools under 
the prefix of '/opt/rtems-4.12'.

I can see from the path the sparc/leon3 bsp you have built the RTEMS 
kernel under the same prefix of "/opt/rtems-4.12/".

This is what I call the "production tools and RTEMS BSP" configuration.

Before I continue I would like you to take a look at the Prefixes and 
Project Sandboxing sections of the upcoming User Guide I am working on ....

https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#prefixes

[ I am about to reorganise this document so this link will fail
   sometime if the future, sorry about this ]

It documents prefixes and it also documents Project Sandboxing. This is 
a way you can arrange the various configuration controlled parts when 
putting a project work-flow together.

Back to the question ...

RTEMS builds a BSP or a series of BSPs for an architecture and installs 
them under a prefix. The build produces a specific instance of RTEMS for 
that BSP and from a configuration point of view there are two 
controlling elements, the RTEMS BSP headers and libraries and the 
version of the tools used. A specific BSP instance must reference the 
tools used to build that instance. You should not use a build of a BSP 
with a different version of the tools. It may work, but that is just 
pure luck.

To have a C compiler know about <rtems.h> we must educate it about the 
possible installed paths and we must teach it about RTEMS BSPs. Without 
both of these pieces of information the compiler cannot assume a path.

We could add a RTEMS BSP option to gcc and then have GCC add a search 
path internally to the BSP. Then we could have gcc take an -isystem path 
and add the BSP specific path. No one has done this given a single -I 
can do the same. The search path is the easier bit.

What happens with the various compiler flags for building the code you 
have to have. The gcc BSP would have to support these. It is important 
you build all the code for RTEMS with same code generation flags.

The linking would need to do the same thing. We currently use a horrible 
specs file hack I would love to see go away.

Would gcc accept such a patch? I do not know. Maybe a gcc plugin could 
do this? Again I have never looked into this.

Chris