markus@x4 tmp % echo "#include<algorithm>" | g++ -x c++ -isystem /usr/include -
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/stl_algo.h:59:0,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/algorithm:62,
                 from <stdin>:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
compilation terminated.
gcc-5 and older is fine.

Yeah, this is known, but I'm afraid there is nothing that can be done easily about it.  Just don't do it.
Well, in theory, we could slow everything down by adding yet another default include directory that would come after /usr/include in the default search scope, and would contain some fallback stdlib.h and math.h for these cases, but that would be too ugly.  So, IMHO just the packages that use this should either know what they are doing and put the C++ STL system headers first, or don't use STL, or don't mess with -isystem for the default directories.  The last one preferred.

If the only difference between "-isystem" and "-I" was the change in the
handling of warnings, the #include_next of stdlib.h in libstdc++ would not be
a problem.
The real problem here is that "-isystem /usr/include" changes the include
search path in a way that is incompatible with "-I /usr/include" e.g.
% cat try.cc
#include <cstdlib>
% g++ -c try.cc
% g++ -I /usr/include -c try.cc
% g++ -isystem /usr/include -c try.cc
In file included from try.cc:1:0:
/proj/testbed/data/travis/cache/gcc/include/c++/6.2.0/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
compilation terminated.
I think you'll find most build systems that do "-isystem /usr/include"
instead of "-I /usr/include" are only using "-isystem" for the change
in the warning behavior.  The change in the include path order is not
wanted...

I don't think anyone would manually add "-isystem /usr/include" ...
but build systems that provide variables for third party headers that
may or may not be installed in /usr/include often trigger this.
e.g. if boost is installed in prefix /pkg, then you want to include
/pkg/include in the search path.   if boost is installed in /usr
then you want /usr/include in the search path.  if you have 
"-isystem ${BOOST_PREFIX}/include" in your CXXFLAGS and BOOST_PREFIX
happens to be set to /usr somewhere earlier, you lose.
For what it's worth, this definitely crops up in cmake-based builds:
https://gitlab.kitware.com/cmake/cmake/issues/16291
I triggered it with cmake and Boost on a Cray.  It is partly cmake's
fault too.  Its handling of CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
isn't correct.

For what it's worth, I'd like to mention that what chuck mentions in the previous post can be used to circumvent the issue:
Setting
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES
manually serves as a workaround until the CMake ticket is closed.
This took me quite a while to understand, so hopefully it helps someone else.

Thanks for reporting and trouble shooting this issue, Markus. This issue also affects the Linuxbrew package manager. See the downstream issue at https://github.com/Linuxbrew/brew/issues/724. It'd be great if this issue were addressed by GCC. Thanks to the trouble shooting here, we can work around the issue in the mean time.
Cheers,
Shaun

(In reply to chuck cranor from comment #3)
> I think you'll find most build systems that do "-isystem /usr/include"
> instead of "-I /usr/include" are only using "-isystem" for the change
> in the warning behavior.  The change in the include path order is not
> wanted...
Then they should stop (mis)using -isystem, since it's clearly documented to affect the order directories are searched:
  If a standard system include directory, or a directory specified with
  -isystem, is also specified with -I, the -I option is ignored.  The directory
  is still searched but as a system directory at its normal position in the
  system include chain.  This is to ensure that GCC's procedure to fix buggy
  system headers and the ordering for the "#include_next" directive are not
  inadvertently changed.  If you really need to change the search order for
  system directories, use the -nostdinc and/or -isystem options.
The corollary is that you shouldn't use it unless you really need to change the search order for system directories!

(In reply to Jonathan Wakely from comment #8)
> (In reply to chuck cranor from comment #3)
> > I think you'll find most build systems that do "-isystem /usr/include"
> > instead of "-I /usr/include" are only using "-isystem" for the change
> > in the warning behavior.  The change in the include path order is not
> > wanted...
> Then they should stop (mis)using -isystem, since it's clearly documented to
> affect the order directories are searched:
>   If a standard system include directory, or a directory specified with
>   -isystem, is also specified with -I, the -I option is ignored.  The
> directory
>   is still searched but as a system directory at its normal position in the
>   system include chain.  This is to ensure that GCC's procedure to fix buggy
>   system headers and the ordering for the "#include_next" directive are not
>   inadvertently changed.  If you really need to change the search order for
>   system directories, use the -nostdinc and/or -isystem options.
> The corollary is that you shouldn't use it unless you really need to change
> the search order for system directories!
About not using it: sure, this works, but now how can a project enable warnings just for their own headers and not those of the whole system?  This seems to be a valid use case.
In GNU Guix, we worked around the new behavior described here for GCC >= 6 by searching headers in CPATH rather than CPLUS_INCLUDE_PATH, because using CPLUS_INCLUDE_PATH would have the headers treated as system headers and break the required ordering of GCC's own headers.  The annoyance with using CPATH is that now warnings are issued for the whole collection of headers rather than just for those of the project being built.
I experimented with using CPLUS_INCLUDE_PATH and recommendations found here about making sure none of GCC's internal include paths were being duplicated through CPLUS_INCLUDE_PATH (e.g., those of glib and gcc) but the compilation still failed like this:
cd /tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/build/src/libnrtype && /gnu/store/br4id28zs2nx3p2r8nr5kfnk3qway45k-gcc-7.5.0/bin/c++  -DHAVE_CONFIG_H -DWITH_CSSBLEND -DWITH_CSSCOMPOSITE -DWITH_MESH -DWITH_SVG2 -I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/build/src/libnrtype -I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/inkscape-1.0beta2_2019-12-03_2b71d25d45/src/libnrtype -I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/inkscape-1.0beta2_2019-12-03_2b71d25d45 -I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/inkscape-1.0beta2_2019-12-03_2b71d25d45/src -I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/build/include -isystem /gnu/store/6081r9b5hdrwwfqljwsqsjqn8qvf18qz-libpng-1.6.37/include/libpng16 -isystem /gnu/store/vsba1vjxy0g47251mrrxrhlpqchlmgr3-libxml2-2.9.10/include/libxml2 -isystem /gnu/store/7y5kcq7pc31rq8y06pfifqi35x3nn0i2-libsoup-minimal-2.68.3/include/libsoup-2.4 -isystem /gnu/store/khyi8q7glb4h3xv1yaq6vq837z9y3rif-freetype-2.10.1/include/freetype2 -isystem /gnu/store/0d49ps0g5knrny1h8ijss65sb4i54dab-util-linux-2.34/include/uuid -isystem /gnu/store/0d49ps0g5knrny1h8ijss65sb4i54dab-util-linux-2.34/include/libmount -isystem /gnu/store/0d49ps0g5knrny1h8ijss65sb4i54dab-util-linux-2.34/include/blkid -isystem /gnu/store/1h4jsfampb408fs3kdzchnvjf21vk5jl-pango-1.42.4/include/pango-1.0 -isystem /gnu/store/rp02xwl91kb42zi2v7pxcc5jrvwixg36-glib-2.62.4/include/glib-2.0 -isystem /gnu/store/rp02xwl91kb42zi2v7pxcc5jrvwixg36-glib-2.62.4/lib/glib-2.0/include -isystem /gnu/store/3vkqx4lxlv09gr1674jw01akipvx9h9f-cairo-1.16.0/include/cairo -isystem /gnu/store/jj5a0qzzh556v8kis0xba69rsdg9v3n1-harfbuzz-2.6.4/include/harfbuzz -isystem /gnu/store/fdvbnbif5giqimfnmlza6ji8jax4lp9z-fribidi-1.0.7/include/fribidi -isystem /gnu/store/i9fi2nwynsigjis0gzlba3jl7s0wygwm-pixman-0.38.4/include/pixman-1 -isystem /gnu/store/01r2pxnkgsi039na193pfnz60di5lwln-libgc-7.6.12/include/gc -isystem /gnu/store/192b5i8pilw4kaysy8d6zsrcvfjaz8k7-poppler-0.83.0/include/poppler -isystem /gnu/store/llg2s8pqpsg4zprzvx0xcdrsaffvap5s-gdl-minimal-3.34.0/include/libgdl-3.0 -isystem /gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/include/gtkmm-3.0 -isystem /gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/lib/gtkmm-3.0/include -isystem /gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/include/gdkmm-3.0 -isystem /gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/lib/gdkmm-3.0/include -isystem /gnu/store/nz5vdsnx0dn7b36fq29fsq502vqzqx9q-gtk+-3.24.12/include/gtk-3.0/unix-print -isystem /gnu/store/nz5vdsnx0dn7b36fq29fsq502vqzqx9q-gtk+-3.24.12/include/gtk-3.0 -isystem /gnu/store/vcz9zfdph8d82d5gcgw8aibw2q58y1ha-glibmm-2.60.0/include/giomm-2.4 -isystem /gnu/store/vcz9zfdph8d82d5gcgw8aibw2q58y1ha-glibmm-2.60.0/lib/giomm-2.4/include -isystem /gnu/store/vcz9zfdph8d82d5gcgw8aibw2q58y1ha-glibmm-2.60.0/include/glibmm-2.4 -isystem /gnu/store/vcz9zfdph8d82d5gcgw8aibw2q58y1ha-glibmm-2.60.0/lib/glibmm-2.4/include -isystem /gnu/store/y9y6c06rb688qah8jh02nyq1yn7lgmg8-atkmm-2.28.0/include/atkmm-1.6 -isystem /gnu/store/xlx1fm4izk93ycm6nzbhbayrszwi3c6v-cairomm-1.12.2/include/cairomm-1.0 -isystem /gnu/store/xlx1fm4izk93ycm6nzbhbayrszwi3c6v-cairomm-1.12.2/lib/cairomm-1.0/include -isystem /gnu/store/sqp3808nfl3wpsb9sb8r35vxjdr74xaq-pangomm-2.42.0/include/pangomm-1.4 -isystem /gnu/store/sqp3808nfl3wpsb9sb8r35vxjdr74xaq-pangomm-2.42.0/lib/pangomm-1.4/include -isystem /gnu/store/vq3680fwrm9rjvcsz1nhik8dvm1xfh03-gdk-pixbuf+svg-2.40.0/include/gdk-pixbuf-2.0 -isystem /gnu/store/12an2dzlv3sfc5jfhbhq5xjbh3l5crhc-atk-2.32.0/include/atk-1.0 -isystem /gnu/store/vn6j6z9ya16rmhkj9k1f9ibg99w6sk4b-at-spi2-atk-2.32.0/include/at-spi2-atk/2.0 -isystem /gnu/store/rp02xwl91kb42zi2v7pxcc5jrvwixg36-glib-2.62.4/include/gio-unix-2.0 -isystem /gnu/store/vzaax511rrszjpzjihh2dj0dflq2zy1v-libsigc++-2.10.2/include/sigc++-2.0 -isystem /gnu/store/vzaax511rrszjpzjihh2dj0dflq2zy1v-libsigc++-2.10.2/lib/sigc++-2.0/include -isystem /gnu/store/y1k369jr0hsll9sx37w1chay1ivm2wjj-libdrm-2.4.99/include/libdrm -isystem /gnu/store/69zp5iqd7cqyl8vxv6jipq1wzw98mv8l-at-spi2-core-minimal-2.32.1/include/at-spi-2.0 -isystem /gnu/store/w13rab0229w2pg9b4610vdgzqsdn9c6k-dbus-1.12.16/include/dbus-1.0 -isystem /gnu/store/w13rab0229w2pg9b4610vdgzqsdn9c6k-dbus-1.12.16/lib/dbus-1.0/include  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Werror=format -Werror=format-security -pthread -fopenmp -O2 -g -DNDEBUG   -pthread -fPIC -std=gnu++11 -o CMakeFiles/nrtype_LIB.dir/FontInstance.cpp.o -c /tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/inkscape-1.0beta2_2019-12-03_2b71d25d45/src/libnrtype/FontInstance.cpp
In file included from /gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include/bits/posix1_lim.h:161:0,
                 from /gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include/limits.h:183,
                 from /gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include-fixed/limits.h:194,
                 from /gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include-fixed/syslimits.h:7,
                 from /gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include-fixed/limits.h:34,
                 from /gnu/store/khyi8q7glb4h3xv1yaq6vq837z9y3rif-freetype-2.10.1/include/freetype2/freetype/config/ftstdlib.h:59,
                 from /gnu/store/khyi8q7glb4h3xv1yaq6vq837z9y3rif-freetype-2.10.1/include/freetype2/freetype/config/ftconfig.h:41,
                 from /gnu/store/khyi8q7glb4h3xv1yaq6vq837z9y3rif-freetype-2.10.1/include/freetype2/freetype/freetype.h:33,
                 from /gnu/store/khyi8q7glb4h3xv1yaq6vq837z9y3rif-freetype-2.10.1/include/freetype2/freetype/ftoutln.h:25,
                 from /tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/inkscape-1.0beta2_2019-12-03_2b71d25d45/src/libnrtype/FontInstance.cpp:22:
/gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include/bits/local_lim.h:38:10: fatal error: linux/limits.h: No such file or directory
 #include <linux/limits.h>
          ^~~~~~~~~~~~~~~~
compilation terminated.
The above -isystem directives were populated by the CMake build system of Inkscape 1.0 beta2, and the environment variable CPLUS_INCLUDE_PATH below was in effect: CPLUS_INCLUDE_PATH:/gnu/store/mvm8lfh6fj8dm2m46bnnyg2ap6v9q57y-linux-libre-headers-4.19.56/include:/gnu/store/18piyd08w9b7j08yz1lj62kkmha3llx1-googletest-1.8.1/include:/gnu/store/0hwmh6bh0kgcmk88za2lsa5bv4vi05ci-bzip2-1.0.6/include:/gnu/store/81b77pazf968avgghvn8rxfrs8k612xw-xz-5.2.4/include:/gnu/store/5q3bwf9y426w38bxbw3jwbhjhr0rmawf-file-5.37/include:/gnu/store/yshmqw3avy3d2w58zd3vmqg5p0khr0bd-gawk-5.0.1/include:/gnu/store/iirahlxlv27dl0rqh3k9p71fcyan1hg2-make-4.2.1/include:/gnu/store/rc6a6s09kmk1g8pa7m8r127yg59lcvhs-binutils-2.33.1/include:/gnu/store/6ifw1pxap7y9flmisg5sip9lpyj9bxxd-aspell-0.60.8/include:/gnu/store/ffsc3ih1hysi4mb8h6xdr0kymbhssbd0-double-conversion-3.1.5/include:/gnu/store/llg2s8pqpsg4zprzvx0xcdrsaffvap5s-gdl-minimal-3.34.0/include:/gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/include:/gnu/store/nz5vdsnx0dn7b36fq29fsq502vqzqx9q-gtk+-3.24.12/include:/gnu/store/knalzdhfjm6jknrm9q039cadw6zl9zx9-gsl-2.6/include:/gnu/store/192b5i8pilw4kaysy8d6zsrcvfjaz8k7-poppler-0.83.0/include:/gnu/store/4cl71hr4ba08b876ajj6l0sg91k9dp13-libjpeg-9c/include:/gnu/store/6081r9b5hdrwwfqljwsqsjqn8qvf18qz-libpng-1.6.37/include:/gnu/store/vsba1vjxy0g47251mrrxrhlpqchlmgr3-libxml2-2.9.10/include:/gnu/store/6aw27kj4j6k1mw3c8z3m085gz46k6hqc-libxslt-1.1.34/include:/gnu/store/01r2pxnkgsi039na193pfnz60di5lwln-libgc-7.6.12/include:/gnu/store/7y5kcq7pc31rq8y06pfifqi35x3nn0i2-libsoup-minimal-2.68.3/include:/gnu/store/khyi8q7glb4h3xv1yaq6vq837z9y3rif-freetype-2.10.1/include:/gnu/store/qm22az1mlbr3p1idp0czn82kdkmhdyln-popt-1.16/include:/gnu/store/zwfw59kvv3891gkpidiz2l0377hsf6fh-potrace-1.15/include:/gnu/store/v0vdzm9fmmicixg3fkr6c9jpbf9h7vq3-lcms-2.9/include:/gnu/store/8b6r1vzl207i5b978xvv77mhm8rbnsz0-boost-1.70.0/include:/gnu/store/w4nbizjyn1das7k4skws2fspzw8nir7k-gettext-minimal-0.20.1/include:/gnu/store/h4im9xr6q3kry43pw5r0rrwkcqkjdaw7-zlib-1.2.11/include:/gnu/store/hjybmczw7ha989200p9cjmsmn2disakv-libselinux-3.0/include:/gnu/store/0d49ps0g5knrny1h8ijss65sb4i54dab-util-linux-2.34/include:/gnu/store/9lwgb7z8p1m0kysbjadjrgjpvrjzj9ws-libffi-3.3/include:/gnu/store/6bmsxp85cnzc9zinv7jx1sm86ip3yapp-pcre-8.43/include:/gnu/store/yx37pnwf56871n0nmf56wm3hwmv3mc33-python-3.7.4/include:/gnu/store/vcz9zfdph8d82d5gcgw8aibw2q58y1ha-glibmm-2.60.0/include:/gnu/store/y9y6c06rb688qah8jh02nyq1yn7lgmg8-atkmm-2.28.0/include:/gnu/store/xlx1fm4izk93ycm6nzbhbayrszwi3c6v-cairomm-1.12.2/include:/gnu/store/sqp3808nfl3wpsb9sb8r35vxjdr74xaq-pangomm-2.42.0/include:/gnu/store/n715a7k336gp1j4gwvyr5jqvq5hixgaa-wayland-1.18.0/include:/gnu/store/1h4jsfampb408fs3kdzchnvjf21vk5jl-pango-1.42.4/include:/gnu/store/9gmxzvw2zap9vbcpxlidn7i2rl1h0r6h-mesa-19.2.1/include:/gnu/store/833l81h0mwv4ar0rnrv3i9jnvr09jmvk-libxrandr-1.5.2/include:/gnu/store/2mznp77d4m8brv9mwj4sahxb7hjz6m0q-libxdamage-1.1.5/include:/gnu/store/5mmq8ck50gzxvxxw0p2p4cgzc0ykvki8-libxkbcommon-0.8.4/include:/gnu/store/pyl4hw1ggm1akzg7drk69ljcdc0fcm96-libxinerama-1.1.4/include:/gnu/store/r1inaxc74m3zpy5x60si5v2vz8mjix48-libxi-1.7.10/include:/gnu/store/i5vmy38792w61i41k8hlzdmmbz3ii7ca-libxcursor-1.2.0/include:/gnu/store/8q3waxhxaxmadwr5ws7qifcqwmjdhqqk-libepoxy-1.5.3/include:/gnu/store/vq3680fwrm9rjvcsz1nhik8dvm1xfh03-gdk-pixbuf+svg-2.40.0/include:/gnu/store/12an2dzlv3sfc5jfhbhq5xjbh3l5crhc-atk-2.32.0/include:/gnu/store/vn6j6z9ya16rmhkj9k1f9ibg99w6sk4b-at-spi2-atk-2.32.0/include:/gnu/store/rp02xwl91kb42zi2v7pxcc5jrvwixg36-glib-2.62.4/include:/gnu/store/10h3cm6rsyjh9lgp46s85pm8jlwfvmrf-sqlite-3.30.1/include:/gnu/store/m7lsc5dyky2c0mdadvz0gaqqazkzbla2-libpsl-0.21.0/include:/gnu/store/df9p8q4za50c59bmln2f89yff6vph5bx-google-brotli-1.0.7/include:/gnu/store/sp19znx65dqzq56fli5475s86dn8b939-libsepol-3.0/include:/gnu/store/vzaax511rrszjpzjihh2dj0dflq2zy1v-libsigc++-2.10.2/include:/gnu/store/3vkqx4lxlv09gr1674jw01akipvx9h9f-cairo-1.16.0/include:/gnu/store/164lwl0dr12x9da52p4wfdra10skh8cr-fontconfig-2.13.1/include:/gnu/store/jj5a0qzzh556v8kis0xba69rsdg9v3n1-harfbuzz-2.6.4/include:/gnu/store/fdvbnbif5giqimfnmlza6ji8jax4lp9z-fribidi-1.0.7/include:/gnu/store/dxj77l1hpgsrxcm80abin4x24zl3ms1d-xorgproto-2019.2/include:/gnu/store/5fvxdqig0384rmcz3inpbvfjiw772yb3-libxxf86vm-1.1.4/include:/gnu/store/48xvy1qjzqn3nlz7wv4bvfv82a2kxwk6-libxshmfence-1.3/include:/gnu/store/ldpwhbs3l6s4qx2y9mvj5hpblpzddvql-libxfixes-5.0.3/include:/gnu/store/d8ikrvmqn5df07llwj1qvpgrr18gams7-libx11-1.6.9/include:/gnu/store/sxyn2wfshm2kdrgsb4iy3h7cja861spf-libvdpau-1.3/include:/gnu/store/y1k369jr0hsll9sx37w1chay1ivm2wjj-libdrm-2.4.99/include:/gnu/store/73pswbvf7a9qfgjk5gh2fc7xbvhz21s4-libxrender-0.9.10/include:/gnu/store/ll0rn5raafbqxnya05175g9ki3hm95a5-libxext-1.3.4/include:/gnu/store/69zp5iqd7cqyl8vxv6jipq1wzw98mv8l-at-spi2-core-minimal-2.32.1/include:/gnu/store/i9fi2nwynsigjis0gzlba3jl7s0wygwm-pixman-0.38.4/include:/gnu/store/dq2lr3mxj5fc4ycsx7q50jxn7drqcwl1-expat-2.2.9/include:/gnu/store/qs93yffifzq8z1pvgdkz8pimrn746wbl-icu4c-65.1/include:/gnu/store/gl14cajxhxl7ck17md3i5q6w7k14vgpf-graphite2-1.3.13/include:/gnu/store/q50c5jwgimqifl5h98cib7iqq556iy2m-libxcb-1.13/include:/gnu/store/5wpib3l68nan7v78my5i6ffcwhzid4gd-libxtst-1.2.3/include:/gnu/store/w13rab0229w2pg9b4610vdgzqsdn9c6k-dbus-1.12.16/include:/gnu/store/ndajhnchm2q4gg99ibnzc9i3rmwsm2kb-libxdmcp-1.1.3/include:/gnu/store/h9682937xqyyv4svh9z5568x9zw6w48j-libxau-1.0.9/include
Could it be because including headers from standard includes (before they are searched) cause them to be loaded (not in the order we'd expect them to?). If confirmed, this would make it even more slippery to use -isystem for anything but messing with the standard include paths.
This bug is closed, but I thought I'd write this here so that it is known that it is still causing headaches at least for some and that the workarounds proposed don't work for all scenarios.

(In reply to Maxim Cournoyer from comment #9)
> About not using it: sure, this works, but now how can a project enable
> warnings just for their own headers and not those of the whole system?  This
> seems to be a valid use case.
This works, but is tedious to do for every warning:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#pragma GCC diagnostic ignored "-Wunused-local-typedefs"
#include <third-party-library/header.h>
#pragma GCC diagnostic pop

(In reply to Jonathan Wakely from comment #10)
> (In reply to Maxim Cournoyer from comment #9)
> > About not using it: sure, this works, but now how can a project enable
> > warnings just for their own headers and not those of the whole system?  This
> > seems to be a valid use case.
> This works, but is tedious to do for every warning:
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> #pragma GCC diagnostic ignored "-Wunused-local-typedefs"
> #include <third-party-library/header.h>
> #pragma GCC diagnostic pop
Thanks for the trick.  Agreed that it is tedious, but still good to know.  About my previous comment saying that the workaround of not including any GCC standard include directory in -isystem (or CPLUS_INCLUDE_PATH), the problem was that I had set CPLUS_INCLUDE_PATH but not C_INCLUDE_PATH, and Inkscape goes on to build bundled libraries which are C, not C++.  Hence, the Linux kernel headers really were not present in any include search path for a C program.  Apologies for the noise.