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

[Mark H Weaver <mhw@netris.org>]

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

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

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

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

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

       Mark