[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, brea
From: |
Marius Bakke |
Subject: |
bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking |
Date: |
Mon, 03 Feb 2020 22:03:54 +0100 |
User-agent: |
Notmuch/0.29.3 (https://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) |
Ludovic Courtès <address@hidden> 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
Description: PGP signature