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

  • Done
  • quality assurance status badge
Details
9 participants
  • Carl Dong
  • Giel van Schijndel
  • julien lepiller
  • Ludovic Courtès
  • Mark Wielaard
  • Maxim Cournoyer
  • Marius Bakke
  • Mark H Weaver
  • Reza Housseini
Owner
unassigned
Submitted by
julien lepiller
Severity
important
J
J
julien lepiller wrote on 9 Mar 2018 13:10
gcc7 doesn't find stdlib.h
(address . bug-guix@gnu.org)
fa5ec97a90a8f52f23fed2654d08078d@lepiller.eu
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:
L
L
Ludovic Courtès wrote on 9 Mar 2018 13:41
control message for bug #30756
(address . control@debbugs.gnu.org)
87lgf1zajg.fsf@gnu.org
severity 30756 important
L
L
Ludovic Courtès wrote on 9 Mar 2018 13:42
Re: bug#30756: gcc7 doesn't find stdlib.h
(name . julien lepiller)(address . julien@lepiller.eu)
87fu59zagv.fsf@gnu.org
julien lepiller <julien@lepiller.eu> skribis:

Toggle quote (6 lines)
> 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:


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’.
L
L
Ludovic Courtès wrote on 4 May 2018 14:43
(name . Giel van Schijndel)(address . giel@mortis.eu)
87d0ybvbep.fsf@gnu.org
Hi,

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

Toggle quote (16 lines)
> 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?
Toggle diff (23 lines)
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
Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 4 May 2018 17:28
(name . Giel van Schijndel)(address . giel@mortis.eu)
87k1sjsan9.fsf@gnu.org
Giel van Schijndel <giel@mortis.eu> skribis:

Toggle quote (2 lines)
> On 04-05-18 14:43, Ludovic Courtès wrote:

[...]

Toggle quote (5 lines)
>> 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:

Toggle snippet (12 lines)
(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))))))

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

Toggle quote (4 lines)
> 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.

Toggle quote (4 lines)
> 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’.
G
G
Giel van Schijndel wrote on 4 May 2018 11:46
5212cd7e-5f52-2826-2f65-9b66af4e73ad@mortis.eu
On 09-03-18 13:42, Ludovic Courtès wrote:
Toggle quote (13 lines)
> 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:

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:
Toggle quote (13 lines)
> $ 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
G
G
Giel van Schijndel wrote on 4 May 2018 16:30
(name . Ludovic Courtès)(address . ludo@gnu.org)
36478fc2-98e7-0ebd-9048-7193fd240f5c@mortis.eu
On 04-05-18 14:43, Ludovic Courtès wrote:
Toggle quote (27 lines)
> 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.

Toggle quote (2 lines)
> 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:

Toggle quote (5 lines)
>           (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
G
G
Giel van Schijndel wrote on 4 May 2018 17:07
(name . Ludovic Courtès)(address . ludo@gnu.org)
39b433d2-bc3b-733f-3210-4a93fcb596c2@mortis.eu
On 04-05-18 16:30, Giel van Schijndel wrote:
Toggle quote (3 lines)
> 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
G
G
Giel van Schijndel wrote on 4 May 2018 18:03
(name . Ludovic Courtès)(address . ludo@gnu.org)
58dc244a-8ff5-fb1f-8c7b-d6745c1f2558@mortis.eu
On 04-05-18 17:28, Ludovic Courtès wrote:
Toggle quote (20 lines)
> 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:
Toggle quote (13 lines)
> 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
M
M
Mark H Weaver wrote on 4 May 2018 18:41
(name . Giel van Schijndel)(address . giel@mortis.eu)
87zi1fid9r.fsf@netris.org
Giel van Schijndel <giel@mortis.eu> writes:

Toggle quote (47 lines)
> 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:


Mark
M
M
Mark H Weaver wrote on 4 May 2018 19:14
(name . Giel van Schijndel)(address . giel@mortis.eu)(address . 30756@debbugs.gnu.org)
87vac3ibrs.fsf@netris.org
Mark H Weaver <mhw@netris.org> writes:

Toggle quote (26 lines)
> 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
L
L
Ludovic Courtès wrote on 4 May 2018 22:39
(name . Mark H Weaver)(address . mhw@netris.org)
87fu37rw8d.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (7 lines)
> 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’.
M
M
Mark H Weaver wrote on 4 May 2018 23:36
(name . Ludovic Courtès)(address . ludo@gnu.org)
87fu37hzms.fsf@netris.org
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (14 lines)
> 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
L
L
Ludovic Courtès wrote on 7 May 2018 12:12
(name . Giel van Schijndel)(address . giel@mortis.eu)
87sh7393lo.fsf@gnu.org
Giel van Schijndel <giel@mortis.eu> skribis:

Toggle quote (42 lines)
> 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’.
M
M
Mark H Weaver wrote on 8 May 2018 01:32
(name . Ludovic Courtès)(address . ludo@gnu.org)
87k1sff3ek.fsf@netris.org
Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:
Toggle quote (3 lines)
> 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: 4aicj1qqdvlvssr14zr8fnmzcbbgf3zk-gjs-1.48.6.drv.gz
L
L
Ludovic Courtès wrote on 8 May 2018 15:21
(name . Mark H Weaver)(address . mhw@netris.org)
87h8ni471j.fsf@gnu.org
Hi Mark,

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

Toggle quote (16 lines)
> 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’.
L
L
Ludovic Courtès wrote on 24 Aug 2018 22:18
control message for bug #30756
(address . control@debbugs.gnu.org)
87in3zlds7.fsf@gnu.org
retitle 30756 GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking #include_next
C
C
Carl Dong wrote on 22 Oct 2019 18:26
GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking #include_next
gpKTmxjFHen4lhTLVrF9P6qLWhzsRUi3V7Iw3YOtKC4aj97i8QPlC_A1fV9d3vfsNXtN8VPH1pqgVSLu7hcJi6M5xupXHaePQv0Pe8oEve0=@carldong.me
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"
M
M
Mark Wielaard wrote on 14 Dec 2019 15:23
Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH
(address . 30756@debbugs.gnu.org)
33fde3bf5afcbddcb553c6095846f4f1be5aae93.camel@klomp.org
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.
R
R
Reza Housseini wrote on 17 Jan 2020 11:23
GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking
(address . 30756@debbugs.gnu.org)
CAGZc64HeO-49EDfKqGmrxWKBLzkWcueE8_PdiTaY+WvMDYy6TA@mail.gmail.com
So what is the workaround for this bug when one wants to use gcc >= 6.0.0
with a cmake build system?
Attachment: file
L
L
Ludovic Courtès wrote on 19 Jan 2020 22:16
(name . Reza Housseini)(address . reza.housseini@gmail.com)
87y2u3qh8b.fsf@gnu.org
Hi,

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

Toggle quote (3 lines)
> 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’.
M
M
Maxim Cournoyer wrote on 20 Jan 2020 04:25
(name . Ludovic Courtès)(address . ludo@gnu.org)
87r1zulsgc.fsf@gmail.com
Hello,

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

Toggle quote (15 lines)
> 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:
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
L
L
Ludovic Courtès wrote on 20 Jan 2020 09:56
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87sgkaik08.fsf@gnu.org
Hi,

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

Toggle quote (12 lines)
> 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’.
M
M
Maxim Cournoyer wrote on 22 Jan 2020 04:04
(name . Ludovic Courtès)(address . ludo@gnu.org)
878sm0kx8b.fsf@gmail.com
Hello,

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

Toggle quote (22 lines)
> 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:

Toggle snippet (6 lines)
(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))

gives:

Toggle snippet (11 lines)
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.

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
L
L
Ludovic Courtès wrote on 23 Jan 2020 21:45
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87wo9hnbp9.fsf@gnu.org
Hello!

Thanks for investigating.

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

Toggle quote (5 lines)
> 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:

Toggle snippet (4 lines)
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:

Toggle snippet (4 lines)
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’.

WDYT?

Ludo’.
L
L
Ludovic Courtès wrote on 3 Feb 2020 10:00
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87blqg2gg5.fsf@gnu.org
Hello comrades!

(+Cc: Marius.)

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

Toggle quote (17 lines)
> ‘%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’.
Toggle diff (100 lines)
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
M
M
Marius Bakke wrote on 3 Feb 2020 22:03
87blqfmlhh.fsf@devup.no
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (36 lines)
> 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".
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl44iroACgkQoqBt8qM6
VPqQ5QgAxbROf3oywrRVHg7D+JcHcLLj+iDAQT2JcD7bCACMYVc/V6ZSbIq5Y0qM
M4Ce5U2ug3VIi2rj+DRriiJbcsdUfVSOAcD6mn59+qnz/4q2M+Gof6OnNWHAohCx
4JI79kj76HkJQg//wutdIDbEKdduzCdA9Zh6NoVGLp39Z608O6XmCaaL8T+8tgcn
+BOD8V4/AS5F5ry3+OUpd/PgzBMNQlaKgrgEnT7RiIE8CC18IaiSZ3q0nR2R6MZh
/PQcEqsYB5M6411N/yVUUgLqGn7SNXPRrnIctrjHxsV1LnP8YBgZn2YaLdRTnYc9
y/MqqUoRxX6agfvFLZp4orwpfbiHcQ==
=OEya
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 4 Feb 2020 12:28
(name . Marius Bakke)(address . mbakke@fastmail.com)
874kw6zj55.fsf@gnu.org
Hello!

Marius Bakke <mbakke@fastmail.com> skribis:

Toggle quote (4 lines)
> 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. ;-)

Toggle quote (4 lines)
> 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’.
L
L
Ludovic Courtès wrote on 6 Feb 2020 18:49
(name . Marius Bakke)(address . mbakke@fastmail.com)
87tv4361xn.fsf@gnu.org
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’.
Closed
M
M
Maxim Cournoyer wrote on 7 Feb 2020 04:39
(name . Ludovic Courtès)(address . ludo@gnu.org)
87ftfnm5gl.fsf@gmail.com
Hello Ludovic,

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

Toggle quote (61 lines)
> 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
L
L
Ludovic Courtès wrote on 7 Feb 2020 12:00
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87r1z68xwa.fsf@gnu.org
Hello,

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

Toggle quote (5 lines)
> 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’.
?
Your comment

This issue is archived.

To comment on this conversation send an email to 30756@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 30756
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch