Hi, I'm compiling GCC to be installed on a non-standard location with a glibc also installed in a non-standard place, both using very recent revisions (Jan 2020). For this I'm using --with-advance-toolchain=<custom-dir> during configuration to instruct GCC to use the newer glibc headers and linker installed on that directory, rather than the ones installed in the system. GCC build is failing due to an undefined macro (__glibc_has_include) used by a system header (bits/statx.h). This macro used to be defined by sys/cdefs.h. Both headers come from glibc, but that specific macro got removed recently (glibc commit bfa864e1645e). During the fixincludes step, GCC is processing headers from /usr/include only. In this process, it 'fixes' bits/statx.h from that tree, which corresponds to an older version of glibc installed on the system (which uses the macro). This fixed header seems to take precedence over other versions of the same header the compiler may find (for example, under <custom-dir>). However, the sys/cdefs.h header used comes from <custom-dir>. Since the macro has been removed from glibc, this header (coming from a recent glibc) does not declare it, but the fixed bits/statx.h (based on an older glibc version installed in the system) uses it, causing the issue. On GCC docs, the --with-advance-toolchain flag is described as: > On 64-bit PowerPC Linux systems, configure the compiler to use the header files, library files, and the dynamic linker from the Advance Toolchain release at instead of the default versions that are provided by the Linux distribution. So shouldn't fixincludes fix headers from the value passed to --with-advance--tolchain instead (or at least in addition to) the default /usr/include, as the system headers we are using come from that first directory? Is this more likely a bug on the fixincludes step or a misconfiguration on my part? Thanks! -- Matheus Castanho
