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: contains an "#include_next " 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 , which is found in .../include/c++ cannot find 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