[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