bug#30756: gcc7 doesn't find stdlib.h

bug#30756: gcc7 doesn't find stdlib.h

[julien lepiller]

Hi,

I'm trying to build a software that requires gcc>=7.2. Unfortunately, 
the process crashes and ends with:

/gnu/store/a4vwdk8r6p6l2mnffz4yaqlr1z6z6w3r-gcc-7.3.0/include/c++/cstdlib:75:15: 
fatal error: stdlib.h: No such file or directory.

What I'm trying to build is called emojicode, and the current version of 
my package definition can be found here: 
https://framagit.org/tyreunom/guix-more/commit/ca9a77ed4b0a3ae50590f8e8abb9175f42094560

bug#30756: gcc7 doesn't find stdlib.h

[Ludovic Courtès]

julien lepiller <julien@lepiller.eu> skribis:

> I'm trying to build a software that requires gcc>=7.2. Unfortunately,
> the process crashes and ends with:
>
> /gnu/store/a4vwdk8r6p6l2mnffz4yaqlr1z6z6w3r-gcc-7.3.0/include/c++/cstdlib:75:15:
> fatal error: stdlib.h: No such file or directory.

On IRC Marius mentioned this bug report:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c3

Note that we use C_INCLUDE_PATH, which is equivalent to ‘-isystem’.
Quoth (gnu packages gcc):

      (native-search-paths
       ;; Use the language-specific variables rather than 'CPATH' because they
       ;; are equivalent to '-isystem' whereas 'CPATH' is equivalent to '-I'.
       ;; The intent is to allow headers that are in the search path to be
       ;; treated as "system headers" (headers exempt from warnings) just like
       ;; the typical /usr/include headers on an FHS system.
       (list (search-path-specification
              (variable "C_INCLUDE_PATH")
              (files '("include")))
             (search-path-specification
              (variable "CPLUS_INCLUDE_PATH")
              (files '("include")))
             (search-path-specification
              (variable "LIBRARY_PATH")
              (files '("lib" "lib64")))))

Ludo’.

bug#30756: gcc7 doesn't find stdlib.h

[Giel van Schijndel]

On 09-03-18 13:42, Ludovic Courtès wrote:
> julien lepiller <julien@lepiller.eu> skribis:
>
>> I'm trying to build a software that requires gcc>=7.2. Unfortunately,
>> the process crashes and ends with:
>>
>> /gnu/store/a4vwdk8r6p6l2mnffz4yaqlr1z6z6w3r-gcc-7.3.0/include/c++/cstdlib:75:15:
>> fatal error: stdlib.h: No such file or directory.
> On IRC Marius mentioned this bug report:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c3
>
> Note that we use C_INCLUDE_PATH, which is equivalent to ‘-isystem’.

This is biting me too for a C++17 project I'm trying to build.

That GCC bug report (Jakub Jellinek) says that you shouldn't be using
-isystem for the default include directories. So I believe these paths
shouldn't get added to CPLUS_INCLUDE_PATH in the first place.

In that bug report there's a link to a CMake bug report with a link to a
solution employed by WebKit:
https://trac.webkit.org/changeset/205672/webkit/trunk/Source/cmake/OptionsCommon.cmake

That solution boils down to executing "g++ -v -E -x c++ /dev/null" and
extracting the list of (default) include directories from its output
then giving CMake that list to ensure it won't ever try to add it with
either -I or -isystem to the preprocessor's search path. I believe a
similar approach should be taken by (gnu packages gcc) (assuming that's
what is responsible for adding this).

To confirm that this works:
> $ env -u CPATH -u C_INCLUDE_PATH -u CPLUS_INCLUDE_PATH c++ -v -E -x
> c++ /dev/null
> ...
> #include <...> search starts here:
>  /gnu/store/f9wi8xs84b29f5igp578hnqfpjnfn4gh-gcc-7.3.0/include/c++
>  /gnu/store/f9wi8xs84b29f5igp578hnqfpjnfn4gh-gcc-7.3.0/include/c++/x86_64-unknown-linux-gnu
>  /gnu/store/f9wi8xs84b29f5igp578hnqfpjnfn4gh-gcc-7.3.0/include/c++/backward
>  /gnu/store/8jp0v7q1g4g87ay94i7h7p54mcw48mf3-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/include
>  /gnu/store/8jp0v7q1g4g87ay94i7h7p54mcw48mf3-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/include-fixed
>  /gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/include
> End of search list.
> ...

To get my C++17 project building I can take the auto-generated
CPLUS_INCLUDE_PATH and just strip every path from it that also occurs in
the above list and set it again with (setenv).

There's two problems with this:

1. It's a workaround for a break in the build environment that would
need to be copy-pasted to every project wishing to build C++ with a
modern GCC
2. My skill at Scheme/Guile isn't good enough to execute the above
command and capture its output from within the build phases, let alone
parse and use its result to clean up CPLUS_INCLUDE_PATH.

-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel

bug#30756: gcc7 doesn't find stdlib.h

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Hi,

Giel van Schijndel <giel@mortis.eu> skribis:

> On 09-03-18 13:42, Ludovic Courtès wrote:
>> julien lepiller <julien@lepiller.eu> skribis:
>>
>>> I'm trying to build a software that requires gcc>=7.2. Unfortunately,
>>> the process crashes and ends with:
>>>
>>> /gnu/store/a4vwdk8r6p6l2mnffz4yaqlr1z6z6w3r-gcc-7.3.0/include/c++/cstdlib:75:15:
>>> fatal error: stdlib.h: No such file or directory.
>> On IRC Marius mentioned this bug report:
>>
>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c3
>>
>> Note that we use C_INCLUDE_PATH, which is equivalent to ‘-isystem’.
>
> This is biting me too for a C++17 project I'm trying to build.

Marius, do you have a link to the exact change in GCC that caused this
regression?

I find it hard to believe that a fix would necessarily “slow everything
down”, as Jakub put it in the report above.

Also it seems clear that in Guix we’ll want a solution that’s not
CMake-specific.

Giel, does the patch below work for you?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 836 bytes --]

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 62b896882..9a82a9e81 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -476,7 +476,17 @@ Go.  It also includes runtime support libraries for these languages.")
                     "pa" "sh" "tilepro" "xtensa")))))
     (inputs
      `(("isl" ,isl)
-       ,@(package-inputs gcc-4.7)))))
+       ,@(package-inputs gcc-4.7)))
+
+    (native-search-paths
+     ;; We have to use 'CPATH' for GCC > 5, not 'C_INCLUDE_PATH' & co., due to
+     ;; <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129>.
+     (list (search-path-specification
+            (variable "CPATH")
+            (files '("include")))
+           (search-path-specification
+            (variable "LIBRARY_PATH")
+            (files '("lib" "lib64")))))))
 
 (define-public gcc-7
   (package

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


Thanks,
Ludo’.

bug#30756: gcc7 doesn't find stdlib.h

[Giel van Schijndel]

On 04-05-18 14:43, Ludovic Courtès wrote:
> Hi,
>
> Giel van Schijndel <giel@mortis.eu> skribis:
>
>> On 09-03-18 13:42, Ludovic Courtès wrote:
>>> julien lepiller <julien@lepiller.eu> skribis:
>>>
>>>> I'm trying to build a software that requires gcc>=7.2. Unfortunately,
>>>> the process crashes and ends with:
>>>>
>>>> /gnu/store/a4vwdk8r6p6l2mnffz4yaqlr1z6z6w3r-gcc-7.3.0/include/c++/cstdlib:75:15:
>>>> fatal error: stdlib.h: No such file or directory.
>>> On IRC Marius mentioned this bug report:
>>>
>>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c3
>>>
>>> Note that we use C_INCLUDE_PATH, which is equivalent to ‘-isystem’.
>> This is biting me too for a C++17 project I'm trying to build.
> Marius, do you have a link to the exact change in GCC that caused this
> regression?
>
> I find it hard to believe that a fix would necessarily “slow everything
> down”, as Jakub put it in the report above.
>
> Also it seems clear that in Guix we’ll want a solution that’s not
> CMake-specific.

Obviously, I wasn't suggesting that. I was just suggesting a similar
approach.

> Giel, does the patch below work for you?

No, just by itself it doesn't. It does add 'CPATH', but doesn't drop
'C_INCLUDE_PATH' and 'CPLUS_INCLUDE_PATH'. With this added to my package
preprocessing succeeds:

>           (add-before 'configure 'fixgcc7
>             (lambda _
>               (unsetenv "C_INCLUDE_PATH")
>               (unsetenv "CPLUS_INCLUDE_PATH")))

But I can no longer build with warnings treated as error at that point,
because I'm getting a ton of warnings inside headers of dependencies
now. With either of '-Wno-error' or '-w' I can build now.

Would it be possible to filter the list of directories added to these
environment variables to exclude those already present in GCC's default
search path? I believe that should solve it in all cases, not just the
CMake one. I'm currently trying to produce a minimal test case, I'll
post it here when I succeed.


-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel

bug#30756: gcc7 doesn't find stdlib.h

[Giel van Schijndel]

On 04-05-18 16:30, Giel van Schijndel wrote:
> I'm currently trying to produce a minimal test case, I'll post it here
> when I succeed. 

I've put the test case at https://git.fsfe.org/giel/hello-cpp17. It only
uses a simple makefile.

PS The web interface doesn't seem to update. Directly cloning that URL
does work though.

-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel

bug#30756: gcc7 doesn't find stdlib.h

[Ludovic Courtès]

Giel van Schijndel <giel@mortis.eu> skribis:

> On 04-05-18 14:43, Ludovic Courtès wrote:

[...]

>> Giel, does the patch below work for you?
>
> No, just by itself it doesn't. It does add 'CPATH', but doesn't drop
> 'C_INCLUDE_PATH' and 'CPLUS_INCLUDE_PATH'.

That’s probably because your package still includes gcc@5 as an implicit
input via ‘cmake-build-system’.

You could use a procedure like this to remove implicit inputs and add
your own GCC variant:

--8<---------------cut here---------------start------------->8---
(define (package-with-specific-compiler p compiler)
  "Return P modified to be built with COMPILER."
  (package
    (inherit p)
    (arguments
     `(#:implicit-inputs? #f ,@(package-arguments p)))
    (native-inputs `(("compiler" ,compiler)
                     ,@(package-native-inputs p)))
    (inputs (append (package-inputs p)
                    (alist-delete "gcc" (standard-packages))))))
--8<---------------cut here---------------end--------------->8---

… where ‘standard-packages’ comes from (guix build-system gnu).

> But I can no longer build with warnings treated as error at that point,
> because I'm getting a ton of warnings inside headers of dependencies
> now. With either of '-Wno-error' or '-w' I can build now.

Yeah, that’s a downside (that was the reason why we switched from CPATH
to C_INCLUDE_PATH a while back), but it could be a reasonable
workaround for now.

> Would it be possible to filter the list of directories added to these
> environment variables to exclude those already present in GCC's default
> search path?

I still don’t fully understand the issue actually.  What’s wrong with
having these directories appear several times in the search path?

The difficulty here will be that search path environment variables in
Guix are populated automatically based on their specifications, so it’s
not all that clear to me where that filtering would happen.

Thanks,
Ludo’.

bug#30756: gcc7 doesn't find stdlib.h

[Giel van Schijndel]

On 04-05-18 17:28, Ludovic Courtès wrote:
> That’s probably because your package still includes gcc@5 as an implicit
> input via ‘cmake-build-system’.
>
> You could use a procedure like this to remove implicit inputs and add
> your own GCC variant:
>
> --8<---------------cut here---------------start------------->8---
> (define (package-with-specific-compiler p compiler)
>   "Return P modified to be built with COMPILER."
>   (package
>     (inherit p)
>     (arguments
>      `(#:implicit-inputs? #f ,@(package-arguments p)))
>     (native-inputs `(("compiler" ,compiler)
>                      ,@(package-native-inputs p)))
>     (inputs (append (package-inputs p)
>                     (alist-delete "gcc" (standard-packages))))))
> --8<---------------cut here---------------end--------------->8---
>
> … where ‘standard-packages’ comes from (guix build-system gnu).
This gives me:
> guix/build-system/cmake.scm:93:0: In procedure cmake-build:
> guix/build-system/cmake.scm:93:0: Unrecognized keyword: #:implicit-inputs?

>> Would it be possible to filter the list of directories added to these
>> environment variables to exclude those already present in GCC's default
>> search path?
> I still don’t fully understand the issue actually.  What’s wrong with
> having these directories appear several times in the search path?
>
> The difficulty here will be that search path environment variables in
> Guix are populated automatically based on their specifications, so it’s
> not all that clear to me where that filtering would happen.

The problem seems to be triggered by glibc appearing on the search path.

I'm not sure about GCC's internals exactly so I'm making one assumption
that causes all of this to make sense to me: if a directory appears
multiples times in the search path it will be searched only the first
time that it's encountered.

So in short: <cstdlib> contains an "#include_next <stdlib.h>"
preprocessor directive. That's a GCC extension that tells the
preprocessor it should only search directories appearing in the search
path _after_ the directory containing the file currently being processed.

Now this is the trimmed down search path that gets produced for g++:

 *
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/include

 * /gnu/store/f9wi8xs84b29f5igp578hnqfpjnfn4gh-gcc-7.3.0/include/c++
 *
/gnu/store/f9wi8xs84b29f5igp578hnqfpjnfn4gh-gcc-7.3.0/include/c++/x86_64-unknown-linux-gnu
 *
/gnu/store/f9wi8xs84b29f5igp578hnqfpjnfn4gh-gcc-7.3.0/include/c++/backward
 *
/gnu/store/8jp0v7q1g4g87ay94i7h7p54mcw48mf3-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/include
 *
/gnu/store/8jp0v7q1g4g87ay94i7h7p54mcw48mf3-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/include-fixed
 *
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/include

The first item gets there through CPLUS_INCLUDE_PATH. The rest of the
list are GCC's defaults. Because the first item is a duplicate of the
last, under the previously stated assumption, this will prevent the
preprocessor from searching it a second time for the last. This means
that <cstdlib>, which is found in .../include/c++ cannot find <stdlib.h>
in the list of directories left to search. Because that list, at that
point, starts at .../c++/x86_64-unknown-linux-gnu and ends at
*-glibc-*/include _but_ because that's a duplicate of a previously seen
item it gets eliminated.

I'm guessing the slow down they claim a workaround would cause that GCC
bug report is caused by having to deal with cycle detection becoming
more complicated if you cannot just remove duplicate entries from the
include path.

-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel

bug#30756: gcc7 doesn't find stdlib.h

[Mark H Weaver]

Giel van Schijndel <giel@mortis.eu> writes:

> On 04-05-18 17:28, Ludovic Courtès wrote:
>> That’s probably because your package still includes gcc@5 as an implicit
>> input via ‘cmake-build-system’.
>>
>> You could use a procedure like this to remove implicit inputs and add
>> your own GCC variant:
>>
>> --8<---------------cut here---------------start------------->8---
>> (define (package-with-specific-compiler p compiler)
>>   "Return P modified to be built with COMPILER."
>>   (package
>>     (inherit p)
>>     (arguments
>>      `(#:implicit-inputs? #f ,@(package-arguments p)))
>>     (native-inputs `(("compiler" ,compiler)
>>                      ,@(package-native-inputs p)))
>>     (inputs (append (package-inputs p)
>>                     (alist-delete "gcc" (standard-packages))))))
>> --8<---------------cut here---------------end--------------->8---
>>
>> … where ‘standard-packages’ comes from (guix build-system gnu).
> This gives me:
>> guix/build-system/cmake.scm:93:0: In procedure cmake-build:
>> guix/build-system/cmake.scm:93:0: Unrecognized keyword: #:implicit-inputs?
>
>>> Would it be possible to filter the list of directories added to these
>>> environment variables to exclude those already present in GCC's default
>>> search path?
>> I still don’t fully understand the issue actually.  What’s wrong with
>> having these directories appear several times in the search path?
>>
>> The difficulty here will be that search path environment variables in
>> Guix are populated automatically based on their specifications, so it’s
>> not all that clear to me where that filtering would happen.
>
> The problem seems to be triggered by glibc appearing on the search path.
>
> I'm not sure about GCC's internals exactly so I'm making one assumption
> that causes all of this to make sense to me: if a directory appears
> multiples times in the search path it will be searched only the first
> time that it's encountered.
>
> So in short: <cstdlib> contains an "#include_next <stdlib.h>"
> preprocessor directive. That's a GCC extension that tells the
> preprocessor it should only search directories appearing in the search
> path _after_ the directory containing the file currently being processed.

I ran into the same problem with our 'gjs' package in the 'core-updates'
branch.  First I added 'gcc-7' to the inputs to work around a different
issue (an internal compiler error in gcc-5), and then I encountered the
exact problem you described above.

On my own private branch, I worked around this problem by adding
"-idirafter <LIBC>/include" to CXXFLAGS, but of course it's not a proper
fix.  My workaround happens to be in Savannah on the
'reproduce-bug-29774' branch:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?h=reproduce-bug-29774&id=87022e2666c5e68e865eb160a4bd8e9cdcc1a955

       Mark

bug#30756: gcc7 doesn't find stdlib.h

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Giel van Schijndel <giel@mortis.eu> writes:
>
>> The problem seems to be triggered by glibc appearing on the search path.
>>
>> I'm not sure about GCC's internals exactly so I'm making one assumption
>> that causes all of this to make sense to me: if a directory appears
>> multiples times in the search path it will be searched only the first
>> time that it's encountered.
>>
>> So in short: <cstdlib> contains an "#include_next <stdlib.h>"
>> preprocessor directive. That's a GCC extension that tells the
>> preprocessor it should only search directories appearing in the search
>> path _after_ the directory containing the file currently being processed.
>
> I ran into the same problem with our 'gjs' package in the 'core-updates'
> branch.  First I added 'gcc-7' to the inputs to work around a different
> issue (an internal compiler error in gcc-5), and then I encountered the
> exact problem you described above.
>
> On my own private branch, I worked around this problem by adding
> "-idirafter <LIBC>/include" to CXXFLAGS, but of course it's not a proper
> fix.  My workaround happens to be in Savannah on the
> 'reproduce-bug-29774' branch:
>
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?h=reproduce-bug-29774&id=87022e2666c5e68e865eb160a4bd8e9cdcc1a955

I forgot to mention that in addition to adding -idirafter, I also had to
remove <LIBC>/include from CPLUS_INCLUDE_PATH.  Without the latter, the
-idirafter directive was ignored as a duplicate.

        Mark

bug#30756: gcc7 doesn't find stdlib.h

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> On my own private branch, I worked around this problem by adding
> "-idirafter <LIBC>/include" to CXXFLAGS, but of course it's not a proper
> fix.  My workaround happens to be in Savannah on the
> 'reproduce-bug-29774' branch:
>
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?h=reproduce-bug-29774&id=87022e2666c5e68e865eb160a4bd8e9cdcc1a955

Perhaps we could achieve the same effect by adding “-idirafter
LIBC/include” to the default spec file, under ‘cpp_options’?
(We’d achieve that by modifying the value of ‘cpp_options’ in
gcc/gcc.c.)

I suppose that would fix the include_next issue that Giel describes?

Ludo’.

bug#30756: gcc7 doesn't find stdlib.h

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> On my own private branch, I worked around this problem by adding
>> "-idirafter <LIBC>/include" to CXXFLAGS, but of course it's not a proper
>> fix.  My workaround happens to be in Savannah on the
>> 'reproduce-bug-29774' branch:
>>
>>   https://git.savannah.gnu.org/cgit/guix.git/commit/?h=reproduce-bug-29774&id=87022e2666c5e68e865eb160a4bd8e9cdcc1a955
>
> Perhaps we could achieve the same effect by adding “-idirafter
> LIBC/include” to the default spec file, under ‘cpp_options’?
> (We’d achieve that by modifying the value of ‘cpp_options’ in
> gcc/gcc.c.)

I guess that it might be better to avoid using -idirafter and instead
pay attention to the order in which the normal include search paths are
populated, and in particular for LIBC to last, but maybe that would be
awkward to arrange, dunno.

       Mark

bug#30756: gcc7 doesn't find stdlib.h

[Ludovic Courtès]

Giel van Schijndel <giel@mortis.eu> skribis:

> On 04-05-18 14:43, Ludovic Courtès wrote:
>> Hi,
>>
>> Giel van Schijndel <giel@mortis.eu> skribis:
>>
>>> On 09-03-18 13:42, Ludovic Courtès wrote:
>>>> julien lepiller <julien@lepiller.eu> skribis:
>>>>
>>>>> I'm trying to build a software that requires gcc>=7.2. Unfortunately,
>>>>> the process crashes and ends with:
>>>>>
>>>>> /gnu/store/a4vwdk8r6p6l2mnffz4yaqlr1z6z6w3r-gcc-7.3.0/include/c++/cstdlib:75:15:
>>>>> fatal error: stdlib.h: No such file or directory.
>>>> On IRC Marius mentioned this bug report:
>>>>
>>>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c3
>>>>
>>>> Note that we use C_INCLUDE_PATH, which is equivalent to ‘-isystem’.
>>> This is biting me too for a C++17 project I'm trying to build.
>> Marius, do you have a link to the exact change in GCC that caused this
>> regression?
>>
>> I find it hard to believe that a fix would necessarily “slow everything
>> down”, as Jakub put it in the report above.
>>
>> Also it seems clear that in Guix we’ll want a solution that’s not
>> CMake-specific.
>
> Obviously, I wasn't suggesting that. I was just suggesting a similar
> approach.
>
>> Giel, does the patch below work for you?
>
> No, just by itself it doesn't. It does add 'CPATH', but doesn't drop
> 'C_INCLUDE_PATH' and 'CPLUS_INCLUDE_PATH'. With this added to my package
> preprocessing succeeds:
>
>>           (add-before 'configure 'fixgcc7
>>             (lambda _
>>               (unsetenv "C_INCLUDE_PATH")
>>               (unsetenv "CPLUS_INCLUDE_PATH")))

I pushed the patch as a stop-gap measure in
91a56b4ab5e714e230c0088fb9f5ce0519efe1a0.

Ludo’.

bug#30756: gcc7 doesn't find stdlib.h

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:
> I pushed the patch as a stop-gap measure in
> 91a56b4ab5e714e230c0088fb9f5ce0519efe1a0.

FYI, this did not fix the build failure of 'gjs' on core-updates.  After
merging 'master' into my private branch based on 'core-updates',
including your commit above, I tried reverting the workarounds for 'gjs'
that I described earlier in this thread, except that I left 'gcc-7' in
the native-inputs.  It failed with the same error as before.

Looking at the full log, I see that in the 'set-paths' phase, although
'CPATH' is now being set thanks to your commit above, 'C_INCLUDE_PATH'
and 'CPLUS_INCLUDE_PATH' are still being set as well.  I guess this is
because gcc-final (based on gcc-5) is still included as an implicit
input for gnu-build-system.

I've attached the full build log below.

       Mark



[-- Attachment #2: Failed build log for gjs on core-updates --]
[-- Type: application/x-gzip, Size: 10479 bytes --]

bug#30756: gcc7 doesn't find stdlib.h

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> I pushed the patch as a stop-gap measure in
>> 91a56b4ab5e714e230c0088fb9f5ce0519efe1a0.
>
> FYI, this did not fix the build failure of 'gjs' on core-updates.  After
> merging 'master' into my private branch based on 'core-updates',
> including your commit above, I tried reverting the workarounds for 'gjs'
> that I described earlier in this thread, except that I left 'gcc-7' in
> the native-inputs.  It failed with the same error as before.
>
> Looking at the full log, I see that in the 'set-paths' phase, although
> 'CPATH' is now being set thanks to your commit above, 'C_INCLUDE_PATH'
> and 'CPLUS_INCLUDE_PATH' are still being set as well.  I guess this is
> because gcc-final (based on gcc-5) is still included as an implicit
> input for gnu-build-system.

Yes, that’s what Giel reported as well, and Giel ended up having to
explicitly unset the *_INCLUDE_PATH variables (which come from the
implicit gcc@5 input, indeed.)

Thanks for your feedback,
Ludo’.

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

[Carl Dong]

Hi all,

I ran into a similar problem in 37870, whereby the mingw-w64 search path was
placed at the top of the search paths, making include_next very grumpy.

Mark: I'm curious as to why -idirafter was not a viable solution to the problem,
as it seems like the perfect way to add a path to the bottom of the list of
search paths. Perhaps there's something more fundamental that I'm missing?

Cheers,
Carl Dong
contact@carldong.me
"I fight for the users"

bug#30756: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

[Mark Wielaard]

I am seeing this issue with guix (GNU Guix)
f69439dff438e59fbd24b76949b8767360f2cd72 using gcc (GCC) 9.2.0.

e.g.

$ cat > t.c 
#include <error.h>

int main()
{
  error (0, 0, "what!?");
  return 0;
}

$ gcc -Wformat -Wformat-nonliteral -Werror -g -O2 -o t t.c
In file included from /home/mark/.guix-profile/include/error.h:52,
                 from t.c:1:
/home/mark/.guix-profile/include/bits/error.h: In function ‘error’:
/home/mark/.guix-profile/include/bits/error.h:39:5: error: format not a
string literal, argument types not checked [-Werror=format-nonliteral]
   39 |     __error_noreturn (__status, __errnum, __format,
__va_arg_pack ());
      |     ^~~~~~~~~~~~~~~~
/home/mark/.guix-profile/include/bits/error.h:41:5: error: format not a
string literal, argument types not checked [-Werror=format-nonliteral]
   41 |     __error_alias (__status, __errnum, __format, __va_arg_pack
());
      |     ^~~~~~~~~~~~~
/home/mark/.guix-profile/include/bits/error.h: In function
‘error_at_line’:
/home/mark/.guix-profile/include/bits/error.h:68:10: error: format not
a string literal, argument types not checked [-Werror=format-
nonliteral]
   68 |          __va_arg_pack ());
      |          ^~~~~~~~~~~~~
/home/mark/.guix-profile/include/bits/error.h:71:7: error: format not a
string literal, argument types not checked [-Werror=format-nonliteral]
   71 |       __format, __va_arg_pack ());
      |       ^~~~~~~~
cc1: all warnings being treated as errors

And indeed only CPATH is set, but not C_INCLUDE_PATH.
unsetting CPATH and setting C_INCLUDE_PATH does resolve the issue.

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

[Reza Housseini]

[-- Attachment #1: Type: text/plain, Size: 101 bytes --]

So what is the workaround for this bug when one wants to use gcc >= 6.0.0
with a cmake build system?

[-- Attachment #2: Type: text/html, Size: 129 bytes --]

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

[Ludovic Courtès]

Hi,

Reza Housseini <reza.housseini@gmail.com> skribis:

> So what is the workaround for this bug when one wants to use gcc >= 6.0.0
> with a cmake build system?

Guix has been using GCC 7.x as its default compiler for some time, and
everything works well, CMake or not.  However, we also switched to using
‘CPATH’ instead of ‘C_INCLUDE_PATH’ to work around this bug.

HTH!

Ludo’.

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

[Maxim Cournoyer]

Hello,

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

> Hi,
>
> Reza Housseini <reza.housseini@gmail.com> skribis:
>
>> So what is the workaround for this bug when one wants to use gcc >= 6.0.0
>> with a cmake build system?
>
> Guix has been using GCC 7.x as its default compiler for some time, and
> everything works well, CMake or not.  However, we also switched to using
> ‘CPATH’ instead of ‘C_INCLUDE_PATH’ to work around this bug.
>
> HTH!
>
> Ludo’.

As has been mentioned by Giel van Schijndel earlier in this bug report,
using CPATH causes warnings to be emitted for core libraries such as
glibc since the headers found in CPATH are not (rightfully) treated as
system headers (and thus not muted by GCC).

That has bitten me here, where I was mislead to think there was a build
issue with the latest Inkscape:
https://gitlab.com/inkscape/inkscape/issues/807.  Many packages will end
up having to disable warnings to cope with this behavior.

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!

Maxim

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

[Ludovic Courtès]

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?

Thanks,
Ludo’.

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

[Maxim Cournoyer]

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

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

[Ludovic Courtès]

Hello!

Thanks for investigating.

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> 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?

No, that sounds pretty unreasonable to me.  :-)

However, I’m sure we should be able to sort things appropriately in
guix/build-system/gnu.scm and/or in ‘%final-inputs’, no?

‘%final-inputs’ order actually looks good:

--8<---------------cut here---------------start------------->8---
scheme@(gnu packages commencement)> (map car %final-inputs)
$2 = ("tar" "gzip" "bzip2" "xz" "file" "diffutils" "patch" "findutils" "gawk" "sed" "grep" "coreutils" "make" "bash" "ld-wrapper" "binutils" "gcc" "libc" "libc:static" "locales")
--8<---------------cut here---------------end--------------->8---

But then it breaks when we add everything:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (map car (bag-transitive-inputs (package->bag coreutils)))
$5 = ("source" "perl" "tar" "gzip" "bzip2" "xz" "file" "diffutils" "patch" "findutils" "gawk" "sed" "grep" "coreutils" "make" "bash" "ld-wrapper" "binutils" "gcc" "libc" "libc:static" "locales" "acl" "gmp" "libcap" "kernel-headers")
--8<---------------cut here---------------end--------------->8---

Here acl, gmp, and libcap should be before libc and all
(‘bag-transitive-inputs’ is used by ‘bag->derivation’.)

So I think we should arrange to have the right order in
‘bag->derivation’.

WDYT?

Ludo’.

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

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]

Hello comrades!

(+Cc: Marius.)

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

> ‘%final-inputs’ order actually looks good:
>
> scheme@(gnu packages commencement)> (map car %final-inputs)
> $2 = ("tar" "gzip" "bzip2" "xz" "file" "diffutils" "patch" "findutils" "gawk" "sed" "grep" "coreutils" "make" "bash" "ld-wrapper" "binutils" "gcc" "libc" "libc:static" "locales")
>
>
> But then it breaks when we add everything:
>
> scheme@(guile-user)> (map car (bag-transitive-inputs (package->bag coreutils)))
> $5 = ("source" "perl" "tar" "gzip" "bzip2" "xz" "file" "diffutils" "patch" "findutils" "gawk" "sed" "grep" "coreutils" "make" "bash" "ld-wrapper" "binutils" "gcc" "libc" "libc:static" "locales" "acl" "gmp" "libcap" "kernel-headers")
>
> Here acl, gmp, and libcap should be before libc and all
> (‘bag-transitive-inputs’ is used by ‘bag->derivation’.)
>
> So I think we should arrange to have the right order in
> ‘bag->derivation’.

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?

Ludo’.


[-- Attachment #2: Type: text/x-patch, Size: 5089 bytes --]

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 851bb02163..473d6b8345 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2014 Andreas Enge <andreas@enge.fr>
 ;;; Copyright © 2012 Nikita Karetnikov <nikita@karetnikov.org>
 ;;; Copyright © 2014, 2015, 2017 Mark H Weaver <mhw@netris.org>
@@ -2303,15 +2303,6 @@ exec ~a/bin/~a-~a -B~a/lib -Wl,-dynamic-linker -Wl,~a/~a \"$@\"~%"
                                            char-set:letter)
                                          ,(package-name lib)))
                              (list gmp-6.0 mpfr mpc))
-                      #t)))
-                (add-before 'configure 'treat-glibc-as-system-header
-                  (lambda* (#:key inputs #:allow-other-keys)
-                    (let ((libc (assoc-ref inputs "libc")))
-                      ;; Make sure Glibc is treated as a "system header" so
-                      ;; #include_next does the right thing.
-                      (for-each (lambda (var)
-                                  (setenv var (string-append libc "/include")))
-                                '("C_INCLUDE_PATH" "CPLUS_INCLUDE_PATH"))
                       #t))))))))
 
     ;; This time we want Texinfo, so we get the manual.  Add
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 40cc9ed631..4c4b63dbd1 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2014, 2015, 2018 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2014, 2015, 2016, 2017, 2019 Ricardo Wurmus <rekado@elephly.net>
 ;;; Copyright © 2015 Andreas Enge <andreas@enge.fr>
@@ -340,7 +340,9 @@ where the OS part is overloaded to denote a specific ABI---into GCC
                (files '("include")))
               (search-path-specification
                (variable "CPLUS_INCLUDE_PATH")
-               (files '("include")))
+               ;; Add 'include/c++' here so that <cstdlib>'s "#include_next
+               ;; <stdlib.h>" finds GCC's <stdlib.h>, not libc's.
+               (files '("include/c++" "include")))
               (search-path-specification
                (variable "LIBRARY_PATH")
                (files '("lib" "lib64")))))
@@ -476,17 +478,7 @@ Go.  It also includes runtime support libraries for these languages.")
                                        "gcc-5.0-libvtv-runpath.patch"))))
     (inputs
      `(("isl" ,isl)
-       ,@(package-inputs gcc-4.7)))
-
-    (native-search-paths
-     ;; We have to use 'CPATH' for GCC > 5, not 'C_INCLUDE_PATH' & co., due to
-     ;; <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129>.
-     (list (search-path-specification
-            (variable "CPATH")
-            (files '("include")))
-           (search-path-specification
-            (variable "LIBRARY_PATH")
-            (files '("lib" "lib64")))))))
+       ,@(package-inputs gcc-4.7)))))
 
 (define-public gcc-7
   (package
diff --git a/guix/build-system/gnu.scm b/guix/build-system/gnu.scm
index 3cc89f8852..6e66f5ffce 100644
--- a/guix/build-system/gnu.scm
+++ b/guix/build-system/gnu.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2019 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -296,13 +296,19 @@ standard packages used as implicit inputs of the GNU build system."
                           `(("source" ,source))
                           '())
                     ,@native-inputs
+
+                    ;; When not cross-compiling, ensure implicit inputs come
+                    ;; last.  That way, libc headers come last, which allows
+                    ;; #include_next to work correctly; see
+                    ;; <https://bugs.gnu.org/30756>.
+                    ,@(if target '() inputs)
                     ,@(if (and target implicit-cross-inputs?)
                           (standard-cross-packages target 'host)
                           '())
                     ,@(if implicit-inputs?
                           (standard-packages)
                           '())))
-    (host-inputs inputs)
+    (host-inputs (if target inputs '()))
 
     ;; The cross-libc is really a target package, but for bootstrapping
     ;; reasons, we can't put it in 'host-inputs'.  Namely, 'cross-gcc' is a

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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

Ludovic Courtès <ludo@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".

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ludovic Courtès]

Hello!

Marius Bakke <mbakke@fastmail.com> skribis:

> 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.

Great.  We’ll make new friends with this patch, I can tell you.  ;-)

> 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".

Yes, though probably as a separate patch, if you don’t mind, because
cross-base is kinda orthogonal.

I’ve started looking at places where we manually fiddle with
CPATH/C_INCLUDE_PATH and found some more in build systems.  But then,
there are also quite a few individual packages that fiddle with it, so
it’ll certainly take some time before we find and address each of these.

Related to that, I’ll be posting a patch that clarifies search path
handling in commencement.scm—not a prerequisite, but a nice bonus IMO.

Thanks,
Ludo’.

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

[Ludovic Courtès]

Pushed as 2073b55e6b964cb8ca15e8c74cb32dac00f05f0d!

I’ve been able to build Python, CMake things, and I think Meson things,
so it’s looking good.

Next we should look at CROSS_CPATH.

Ludo’.

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

[Maxim Cournoyer]

Hello Ludovic,

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

> Hello comrades!
>
> (+Cc: Marius.)
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> ‘%final-inputs’ order actually looks good:
>>
>> scheme@(gnu packages commencement)> (map car %final-inputs)
>> $2 = ("tar" "gzip" "bzip2" "xz" "file" "diffutils" "patch" "findutils" "gawk" "sed" "grep" "coreutils" "make" "bash" "ld-wrapper" "binutils" "gcc" "libc" "libc:static" "locales")
>>
>>
>> But then it breaks when we add everything:
>>
>> scheme@(guile-user)> (map car (bag-transitive-inputs (package->bag coreutils)))
>> $5 = ("source" "perl" "tar" "gzip" "bzip2" "xz" "file" "diffutils" "patch" "findutils" "gawk" "sed" "grep" "coreutils" "make" "bash" "ld-wrapper" "binutils" "gcc" "libc" "libc:static" "locales" "acl" "gmp" "libcap" "kernel-headers")
>>
>> Here acl, gmp, and libcap should be before libc and all
>> (‘bag-transitive-inputs’ is used by ‘bag->derivation’.)
>>
>> So I think we should arrange to have the right order in
>> ‘bag->derivation’.
>
> 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?
>
> Ludo’.

Thank you for working on a fix, and properly understanding the root
cause of the problem.  I've reviewed it and it seems great!  I see that
it is already in core-updates.  I will go ahead and proceed with
rebuilding the world and see what ensues! :-)

Cheers,

Maxim

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

[Ludovic Courtès]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Thank you for working on a fix, and properly understanding the root
> cause of the problem.  I've reviewed it and it seems great!  I see that
> it is already in core-updates.  I will go ahead and proceed with
> rebuilding the world and see what ensues! :-)

Thank you!  Let me know if anything doesn’t work as advertised!

Ludo’.