PR gdb/30214: Prefer local include paths to system include paths

  Some systems may install binutils headers into a system location
(e.g. /usr/local/include on FreeBSD) which may also include headers
for other external packages used by GDB such as zlib or zstd.  If a
system include path such as /usr/local/include is added before local
include paths to directories within a clone or release tarball, then
headers from the external binutils package are used which can result
in build failures if the external binutils package is out of sync with
the version of GDB being built.

To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
for "local" componenets before external components.
---
 gdb/Makefile.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

On 3/9/23 1:23 PM, John Baldwin wrote:
> Some systems may install binutils headers into a system location
> (e.g. /usr/local/include on FreeBSD) which may also include headers
> for other external packages used by GDB such as zlib or zstd.  If a
> system include path such as /usr/local/include is added before local
> include paths to directories within a clone or release tarball, then
> headers from the external binutils package are used which can result
> in build failures if the external binutils package is out of sync with
> the version of GDB being built.
> 
> To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
> for "local" componenets before external components.
> ---
>   gdb/Makefile.in | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
> index 6e39383eb93..40497541880 100644
> --- a/gdb/Makefile.in
> +++ b/gdb/Makefile.in
> @@ -629,8 +629,8 @@ INTERNAL_CPPFLAGS = $(CPPFLAGS) @GUILE_CPPFLAGS@ @PYTHON_CPPFLAGS@ \
>   # INTERNAL_CFLAGS is the aggregate of all other *CFLAGS macros.
>   INTERNAL_CFLAGS_BASE = \
>   	$(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
> -	$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) $(ZLIBINC) \
> -	$(ZSTD_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
> +	$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
> +	$(READLINE_CFLAGS) $(ZLIBINC) $(ZSTD_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
>   	$(INTL_CFLAGS) $(INCGNU) $(INCSUPPORT) $(LIBBACKTRACE_INC) \
>   	$(ENABLE_CFLAGS) $(INTERNAL_CPPFLAGS) $(SRCHIGH_CFLAGS) \
>   	$(TOP_CFLAGS) $(PTHREAD_CFLAGS) $(DEBUGINFOD_CFLAGS) $(GMPINC) \

This came out of a thread on gdb@.  It is a candidate for gdb-13-branch
as well as master.
  

>>>>> "John" == John Baldwin <jhb@FreeBSD.org> writes:

John> Some systems may install binutils headers into a system location
John> (e.g. /usr/local/include on FreeBSD) which may also include headers
John> for other external packages used by GDB such as zlib or zstd.  If a
John> system include path such as /usr/local/include is added before local
John> include paths to directories within a clone or release tarball, then
John> headers from the external binutils package are used which can result
John> in build failures if the external binutils package is out of sync with
John> the version of GDB being built.

It seems a little weird that configure would ever end up with
-I/usr/local/include but maybe that's some pkg-config weirdness or maybe
some platforms don't include that by default so it's needed.

John> To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
John> for "local" componenets before external components.

Could you add this trailer to the commit message?

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214


Also I think it's fine to apply this to the gdb 13 branch.

Reviewed-By: Tom Tromey <tom@tromey.com>

thanks,
Tom
  

On 3/10/23 6:43 AM, Tom Tromey wrote:
>>>>>> "John" == John Baldwin <jhb@FreeBSD.org> writes:
> 
> John> Some systems may install binutils headers into a system location
> John> (e.g. /usr/local/include on FreeBSD) which may also include headers
> John> for other external packages used by GDB such as zlib or zstd.  If a
> John> system include path such as /usr/local/include is added before local
> John> include paths to directories within a clone or release tarball, then
> John> headers from the external binutils package are used which can result
> John> in build failures if the external binutils package is out of sync with
> John> the version of GDB being built.
> 
> It seems a little weird that configure would ever end up with
> -I/usr/local/include but maybe that's some pkg-config weirdness or maybe
> some platforms don't include that by default so it's needed.

On FreeBSD it is the latter.  Compilers on FreeBSD only include the base
system (/usr/include and /usr/lib) by default and require explicit -I
and -L to find "external" packages (which all end up under /usr/local).
AFAIK, the other BSD's are similar in this regard.