[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include

2020-01-20 Thread maxim.cournoyer at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

Maxim Cournoyer  changed:

   What|Removed |Added

 CC||maxim.cournoyer at gmail dot 
com

--- Comment #9 from Maxim Cournoyer  ---
(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/n

[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include

2020-01-21 Thread maxim.cournoyer at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

--- Comment #11 from Maxim Cournoyer  ---
(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 
> #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.