https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118700
--- Comment #6 from Christian Menard <christian.menard at gmx dot de> --- Thanks. At least -fno-canonical-system-headers serves as a workaround. To me, it does not seem like the reported behavior is by design. The discussion in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61918 and in the patch that added the -fno-canonical-system-header flag (https://gcc.gnu.org/legacy-ml/gcc-patches/2012-09/msg00459.html) discuss canonicalization purely to improve diagnostics. Quote from the patch: > Libcpp may canonicalize system header paths with lrealpath() for diagnostics, > dependency output, and similar. If gcc is held in a symlink farm the > canonicalized paths may be meaningless to users, and will also conflict with > build frameworks that (for example) disallow absolute paths to header files. > > This change adds -f[no-]canonical-system-headers to the gcc command line, and > a configure option --[en/dis]able-canonical-system-headers to set default > behaviour, allowing the user to select whether or not to implement r186991. > Default is enabled. See also PR c++/52974. This does not suggest any intended changes to the header include resolution. Moreover, it is unclear why canonicalizing paths internally would change how headers are resolved. The fact that the reported behavior depends on how user provided directories are named suggests a bug.
