bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello,

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

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> It'd be nice to find a correct solution, but it seems I can't even make
>> the build system of Inkscape work after switching from CPATH to
>> CPLUS_INCLUDE_PATH and stripping it from any glibc/gcc include
>> directories (I don't get the "stdlib.h: No such file or directory."
>> error anymore, but I now get:
>> "/gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include/bits/errno.h:26:11:
>> fatal error: linux/errno.h: No such file or directory" instead, which I
>> don't understand).
>>
>> I also tried moving the glibc include directory to the end of
>> CPLUS_INCLUDE_PATH and it would still wouldn't be happy.  Hmmph!
>
> Oh, really?  I think that, as Mark H Weaver mentioned in this thread, if
> we make sure that glibc comes next-to-last (before Linux-libre headers)
> and appears only once in the list, it should work.
>
> Can you confirm?

OK, so the errors I was getting about linux/errno.h missing was caused
by my omission to *also* set C_INCLUDE_PATH to the content of CPATH,
because Inkscape goes on building some bundled libraries which are C and
not C++.

After this was understood, Inkscape now builds successfully by simply
taking out glibc from the inputs.  Keeping GCC headers in seems OK,
although I reckon if we fix this at the core (by extending what can be
done which search path specifications) we should take it out as it could
potentially cause problems:  GCC keeps a reference to its own standard
include directories, as shown by the command 'echo | ~a/bin/c++ -E
-Wp,-v -').  On core-updates, this command, when ran in the following
phase:

--8<---------------cut here---------------start------------->8---
(add-before 'set-paths 'show-g++-internal-paths
  (lambda* (#:key inputs #:allow-other-keys)
    (system (format #f "echo | ~a/bin/c++ -E -Wp,-v -" (assoc-ref inputs "gcc")))
    #t))
--8<---------------cut here---------------end--------------->8---

gives:

--8<---------------cut here---------------start------------->8---
starting phase `show-g++-internal-paths'
ignoring nonexistent directory "/no-gcc-local-prefix/include"
ignoring nonexistent directory "/gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/../../../../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include
 /gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include-fixed
 /gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include
End of search list.
--8<---------------cut here---------------end--------------->8---

which lists references to GCC itself as well as to glibc.

The use of -idirafter is to append a headers directory after
*everything* else, including the compiler's own standard include paths.
I think that to -idirafter glibc shouldn't have any effect, since glibc
headers are already in the standard include path, and IIUC GCC will scan
a header directory only once (the first time it encounters it).  The GCC
manual lists the include directories order as (c.f. the node 'Options
for Directory Search' of the GCC reference manual):

       1. For the quote form of the include directive, the directory of
          the current file is searched first.

       2. For the quote form of the include directive, the directories
          specified by '-iquote' options are searched in left-to-right
          order, as they appear on the command line.

       3. Directories specified with '-I' options are scanned in
          left-to-right order.

       4. Directories specified with '-isystem' options are scanned in
          left-to-right order.

       5. Standard system directories are scanned.

       6. Directories specified with '-idirafter' options are scanned in
          left-to-right order.

It'd be very cool to embed arbitrary logic such as sorting, filtering,
or whatever else we need doing directly in a search path specification
:-).  Do you thing this could be done?  Perhaps Gexps could be useful
for this?

Maxim