GNU bug report logs - #30756
GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking #include_next

Previous Next

Full log

View this message in rfc822 format

From: Marius Bakke <mbakke <at> fastmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: reza.housseini <at> gmx.ch, 30756 <at> debbugs.gnu.org, Reza Housseini <reza.housseini <at> gmail.com>
Subject: bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking
Date: Mon, 03 Feb 2020 22:03:54 +0100

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> The attached patch does three things:
>
>   1. Fix the order of inputs computed by (@@ (guix build-system gnu)
>      lower) so that implicit inputs come last.  In particular, this
>      ensures that libc headers and kernel headers come last.  All user
>      libraries passed as ‘inputs’ appear before libc, so they can
>      #include_next a libc header.
>
>   2. Add “include/c++” to the list of directories of
>      ‘CPLUS_INCLUDE_PATH’.  This is a not-so-elegant hack; the main
>      purpose here is to make sure the gcc/libstdc++ include directory
>      appears twice in the search path, so that this chain of include
>      works as expected:
>
>        <cstdlib> (GCC): #include_next <stdlib.h>
>        → <stdlib.h> (GCC): #include_next <stdlib.h>
>        → <stdlib.h> (libc)
>
>   3. Switch back to ‘C_INCLUDE_PATH’ & co. instead of ‘CPATH’ (yay!).
>
> I’ve tested it with “guix build coreutils”, which involved building GMP
> with its C++ bindings, making it a rather good test.  However, more
> testing is needed.
>
> There’s potential for breakage in all the places where we’ve manually
> fiddled with C{,PLUS}_INCLUDE_PATH.  I guess we’ll have to review all of
> them.
>
> Since it fixes a rather serious issue for C/C++ developers (they’d
> rather not see warnings about system headers) but also for packaging
> (‘-Werror’ breaks for warnings that shouldn’t be there in the first
> place), I’d like to propose merging it in this ‘core-updates’ cycle.
> But let’s face it: it’ll keep us busy for a bit.  :-)
>
> Thoughts?

The patch looks great to me.  Love how simple your solution was.  The
#include_next issue be confusing and frustrating even for seasoned Guix
developers, so I'm all for getting it in ASAP.

Can you check whether (gnu packages cross-base) can be adjusted in the
same vein?  I.e. go back to CROSS_C_INCLUDE_PATH & co, and dropping the
'treat-glibc-as-system-header' phase from "cross-gcc-arguments".

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.