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

DoneSubmitted by julien lepiller.
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
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: https://framagit.org/tyreunom/guix-more/commit/ca9a77ed4b0a3ae50590f8e8abb9175f42094560
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:
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’.
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 thisregression?
I find it hard to believe that a fix would necessarily “slow everythingdown”, as Jakub put it in the report above.
Also it seems clear that in Guix we’ll want a solution that’s notCMake-specific.
Giel, does the patch below work for you?
Toggle diff (23 lines)diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scmindex 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 implicitinput via ‘cmake-build-system’.
You could use a procedure like this to remove implicit inputs and addyour 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 CPATHto C_INCLUDE_PATH a while back), but it could be a reasonableworkaround 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 withhaving these directories appear several times in the search path?
The difficulty here will be that search path environment variables inGuix are populated automatically based on their specifications, so it’snot 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 pathsshouldn'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 asolution 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" andextracting the list of (default) include directories from its outputthen giving CMake that list to ensure it won't ever try to add it witheither -I or -isystem to the preprocessor's search path. I believe asimilar approach should be taken by (gnu packages gcc) (assuming that'swhat 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-generatedCPLUS_INCLUDE_PATH and just strip every path from it that also occurs inthe 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 wouldneed to be copy-pasted to every project wishing to build C++ with amodern GCC2. My skill at Scheme/Guile isn't good enough to execute the abovecommand and capture its output from within the build phases, let aloneparse 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 similarapproach.
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 packagepreprocessing 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 dependenciesnow. With either of '-Wno-error' or '-w' I can build now.
Would it be possible to filter the list of directories added to theseenvironment variables to exclude those already present in GCC's defaultsearch path? I believe that should solve it in all cases, not just theCMake one. I'm currently trying to produce a minimal test case, I'llpost 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 onlyuses a simple makefile.
PS The web interface doesn't seem to update. Directly cloning that URLdoes 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 assumptionthat causes all of this to make sense to me: if a directory appearsmultiples times in the search path it will be searched only the firsttime that it's encountered.
So in short: <cstdlib> contains an "#include_next <stdlib.h>"preprocessor directive. That's a GCC extension that tells thepreprocessor it should only search directories appearing in the searchpath _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 thelist are GCC's defaults. Because the first item is a duplicate of thelast, under the previously stated assumption, this will prevent thepreprocessor from searching it a second time for the last. This meansthat <cstdlib>, which is found in .../include/c++ cannot find <stdlib.h>in the list of directories left to search. Because that list, at thatpoint, starts at .../c++/x86_64-unknown-linux-gnu and ends at*-glibc-*/include _but_ because that's a duplicate of a previously seenitem it gets eliminated.
I'm guessing the slow down they claim a workaround would cause that GCCbug report is caused by having to deal with cycle detection becomingmore complicated if you cannot just remove duplicate entries from theinclude 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 differentissue (an internal compiler error in gcc-5), and then I encountered theexact 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 properfix. 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
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 toremove <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 “-idirafterLIBC/include” to the default spec file, under ‘cpp_options’?(We’d achieve that by modifying the value of ‘cpp_options’ ingcc/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 insteadpay attention to the order in which the normal include search paths arepopulated, and in particular for LIBC to last, but maybe that would beawkward 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 in91a56b4ab5e714e230c0088fb9f5ce0519efe1a0.
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. Aftermerging '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' inthe 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 isbecause gcc-final (based on gcc-5) is still included as an implicitinput for gnu-build-system.
I've attached the full build log below.
Mark
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 toexplicitly unset the *_INCLUDE_PATH variables (which come from theimplicit 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 wasplaced 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 ofsearch paths. Perhaps there's something more fundamental that I'm missing?
Cheers,Carl Dongcontact@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.cIn 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 astring 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 astring 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 nota 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 astring 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.0with 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, andeverything 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 asglibc since the headers found in CPATH are not (rightfully) treated assystem headers (and thus not muted by GCC).
That has bitten me here, where I was mislead to think there was a buildissue with the latest Inkscape:https://gitlab.com/inkscape/inkscape/issues/807. Many packages will endup 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 makethe build system of Inkscape work after switching from CPATH toCPLUS_INCLUDE_PATH and stripping it from any glibc/gcc includedirectories (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 Idon't understand).
I also tried moving the glibc include directory to the end ofCPLUS_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, ifwe 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 causedby my omission to *also* set C_INCLUDE_PATH to the content of CPATH,because Inkscape goes on building some bundled libraries which are C andnot C++.
After this was understood, Inkscape now builds successfully by simplytaking 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 bedone which search path specifications) we should take it out as it couldpotentially cause problems: GCC keeps a reference to its own standardinclude directories, as shown by the command 'echo | ~a/bin/c++ -E-Wp,-v -'). On core-updates, this command, when ran in the followingphase:
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/includeEnd 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 glibcheaders are already in the standard include path, and IIUC GCC will scana header directory only once (the first time it encounters it). The GCCmanual lists the include directories order as (c.f. the node 'Optionsfor 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 usefulfor 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 inguix/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 GMPwith its C++ bindings, making it a rather good test. However, moretesting is needed.
There’s potential for breakage in all the places where we’ve manuallyfiddled with C{,PLUS}_INCLUDE_PATH. I guess we’ll have to review all ofthem.
Since it fixes a rather serious issue for C/C++ developers (they’drather not see warnings about system headers) but also for packaging(‘-Werror’ breaks for warnings that shouldn’t be there in the firstplace), 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.scmindex 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. Adddiff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scmindex 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 (packagediff --git a/guix/build-system/gnu.scm b/guix/build-system/gnu.scmindex 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 Guixdevelopers, so I'm all for getting it in ASAP.
Can you check whether (gnu packages cross-base) can be adjusted in thesame 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-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl44iroACgkQoqBt8qM6VPqQ5QgAxbROf3oywrRVHg7D+JcHcLLj+iDAQT2JcD7bCACMYVc/V6ZSbIq5Y0qMM4Ce5U2ug3VIi2rj+DRriiJbcsdUfVSOAcD6mn59+qnz/4q2M+Gof6OnNWHAohCx4JI79kj76HkJQg//wutdIDbEKdduzCdA9Zh6NoVGLp39Z608O6XmCaaL8T+8tgcn+BOD8V4/AS5F5ry3+OUpd/PgzBMNQlaKgrgEnT7RiIE8CC18IaiSZ3q0nR2R6MZh/PQcEqsYB5M6411N/yVUUgLqGn7SNXPRrnIctrjHxsV1LnP8YBgZn2YaLdRTnYc9y/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, becausecross-base is kinda orthogonal.
I’ve started looking at places where we manually fiddle withCPATH/C_INCLUDE_PATH and found some more in build systems. But then,there are also quite a few individual packages that fiddle with it, soit’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 pathhandling 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 rootcause of the problem. I've reviewed it and it seems great! I see thatit is already in core-updates. I will go ahead and proceed withrebuilding 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 email to 30756@debbugs.gnu.org