Giel van Schijndel writes: > On 04-05-18 17:28, Ludovic Courtès wrote: >> That’s probably because your package still includes gcc@5 as an implicit >> input via ‘cmake-build-system’. >> >> You could use a procedure like this to remove implicit inputs and add >> your own GCC variant: >> >> --8<---------------cut here---------------start------------->8--- >> (define (package-with-specific-compiler p compiler) >> "Return P modified to be built with COMPILER." >> (package >> (inherit p) >> (arguments >> `(#:implicit-inputs? #f ,@(package-arguments p))) >> (native-inputs `(("compiler" ,compiler) >> ,@(package-native-inputs p))) >> (inputs (append (package-inputs p) >> (alist-delete "gcc" (standard-packages)))))) >> --8<---------------cut here---------------end--------------->8--- >> >> … where ‘standard-packages’ comes from (guix build-system gnu). > This gives me: >> guix/build-system/cmake.scm:93:0: In procedure cmake-build: >> guix/build-system/cmake.scm:93:0: Unrecognized keyword: #:implicit-inputs? > >>> Would it be possible to filter the list of directories added to these >>> environment variables to exclude those already present in GCC's default >>> search path? >> I still don’t fully understand the issue actually. What’s wrong with >> having these directories appear several times in the search path? >> >> The difficulty here will be that search path environment variables in >> Guix are populated automatically based on their specifications, so it’s >> not all that clear to me where that filtering would happen. > > The problem seems to be triggered by glibc appearing on the search path. > > I'm not sure about GCC's internals exactly so I'm making one assumption > that causes all of this to make sense to me: if a directory appears > multiples times in the search path it will be searched only the first > time that it's encountered. > > So in short: 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. 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 /include" to CXXFLAGS, but of course it's not a proper fix. My workaround happens to be in Savannah on the 'reproduce-bug-29774' branch: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=reproduce-bug-29774&id=87022e2666c5e68e865eb160a4bd8e9cdcc1a955 Mark