On 14/4/2023 1:32 am, Joel Sherrill wrote: > On Thu, Apr 13, 2023 at 8:49 AM Will <nyphb...@gmail.com > <mailto:nyphb...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel