Mark H Weaver <m...@netris.org> writes:
> Giel van Schijndel <g...@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
