[PATCH] spec/bsp/makecustom: Make BSP include path a system include path

Chris Johns chrisj at rtems.org
Thu Apr 13 22:11:11 UTC 2023


On 14/4/2023 1:32 am, Joel Sherrill wrote:
> On Thu, Apr 13, 2023 at 8:49 AM Will <nyphbl8d at gmail.com
> <mailto:nyphbl8d at gmail.com>> wrote:
> 
>     This change is fine, but it also needs the packageconfig change to match.
>     The thread from October has the full patch (title was "[PATCH v2]
>     spec/pkgconfig: Allow builds to override headers"). This also needs a change
>     to libbsd to account for this alteration, IIRC.

Yes it does and thanks for raising this. I will pick up your changes as well.

> This is OK but the use of -B added to the system header file and library include
> paths. If we don't want to use -B any longer,

GCC says:

 -Bprefix

    This option specifies where to find the executables, libraries,
    include files, and data files of the compiler itself.

I think -isystem is the option we want. The documentation says:

  The -isystem and -idirafter options also mark the directory as a
  system directory, so that it gets the same special treatment that
  is applied to the standard system directories.

Ref: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options

> there is likely a system library include argument that is needed.

That is not an issue with the packages I am dealing with. In Makefile.inc the
include path is part of CPPFLAGS and not LDFLAGS.

> And -B had nothing to do with the spec file except

Ah yes I was wrong.

> that it also told gcc where
> it was since it added that base directory as a system directory.

The documentation would indicate it is a compiler path and the -isystem path is
a system include path. We support builds with the tools (ie compiler) in one
path and RTEMS headers in another.

Chris


More information about the devel mailing list