Canadian Cross libstdc++ build fails to find `max_align_t` unless GCC include path is manually added

[Jonathan Wakely]

You've been banned from this mailing list, creating a new email
account doesn't hide who you are.

On Mon, 16 Mar 2026 at 08:38, coshvji cujmlqef <oyzawqgcfc@gmail.com> wrote:
>
> Hello,
>
> I am reporting an issue encountered when building libstdc++ in a Canadian Cross toolchain configuration. I would like to confirm whether this behavior is expected or if it indicates a missing include path during the build.
>
> Some libc implementations (such as DJGPP’s libc) do not provide `max_align_t`. Normally this is not a problem, because GCC’s own headers (from libgcc, e.g. gcc/include/stddef.h) provide a definition of `max_align_t`. When using the newly built cross compiler directly, libstdc++ correctly picks up this header.
>
> However, during a Canadian Cross build, libstdc++ is compiled using the host compiler, and it appears that the target GCC include directory:
>
>     $target/lib/gcc/$target/$version/include
>
> is not added to the include search path. As a result, libstdc++ fails to see the `max_align_t` definition provided by libgcc, and the build fails with:
>
>     /home/test/toolchains_build/gcc/libstdc++-v3/include/cstddef:66:11: error: 'max_align_t' has not been declared in '::'
>        66 |   using ::max_align_t;
>           |           ^~~~~~~~~~~
>
> Below is the failing command (paths unchanged except replacing the username as requested):
>
> Failed command:
>
>     i586-msdosdjgpp-c++ -isystem /home/test/toolchains/gnu/x86_64-w64-mingw32/i586-msdosdjgpp/i586-msdosdjgpp/include -isystem /home/test/toolchains/gnu/x86_64-w64-mingw32/i586-msdosdjgpp/i586-msdosdjgpp/sys-include \
>       -x c++-header -nostdinc++ -g -O2 \
>       -I/home/test/toolchains_build/toolchainbuildscripts/gcc/.artifacts/gcc/x86_64-w64-mingw32/i586-msdosdjgpp/gcc/i586-msdosdjgpp/libstdc++-v3/include/i586-msdosdjgpp \
>       -I/home/test/toolchains_build/toolchainbuildscripts/gcc/.artifacts/gcc/x86_64-w64-mingw32/i586-msdosdjgpp/gcc/i586-msdosdjgpp/libstdc++-v3/include \
>       -I/home/test/toolchains_build/gcc/libstdc++-v3/libsupc++ \
>       -I/home/test/toolchains/gnu/x86_64-w64-mingw32/i586-msdosdjgpp/include \
>       -O2 -g -std=gnu++0x \
>       /home/test/toolchains_build/gcc/libstdc++-v3/include/precompiled/stdc++.h \
>       -o i586-msdosdjgpp/bits/stdc++.h.gch/O2ggnu++0x.gch
>
> The build succeeds if I manually add the GCC include directory:
>
> Successful command (added GCC include path):
>
>     i586-msdosdjgpp-c++ -isystem /home/test/toolchains/gnu/x86_64-w64-mingw32/i586-msdosdjgpp/i586-msdosdjgpp/include -isystem /home/test/toolchains/gnu/x86_64-w64-mingw32/i586-msdosdjgpp/i586-msdosdjgpp/sys-include \
>       -x c++-header -nostdinc++ -g -O2 \
>       -I/home/test/toolchains_build/toolchainbuildscripts/gcc/.artifacts/gcc/x86_64-w64-mingw32/i586-msdosdjgpp/gcc/i586-msdosdjgpp/libstdc++-v3/include/i586-msdosdjgpp \
>       -I/home/test/toolchains_build/toolchainbuildscripts/gcc/.artifacts/gcc/x86_64-w64-mingw32/i586-msdosdjgpp/gcc/i586-msdosdjgpp/libstdc++-v3/include \
>       -I/home/test/toolchains_build/gcc/libstdc++-v3/libsupc++ \
>       -I/home/test/toolchains/gnu/x86_64-w64-mingw32/i586-msdosdjgpp/include \
>       -I/home/test/toolchains_build/toolchainbuildscripts/gcc/.artifacts/gcc/x86_64-w64-mingw32/i586-msdosdjgpp/gcc/gcc/include \
>       -O2 -g -std=gnu++0x \
>       /home/test/toolchains_build/gcc/libstdc++-v3/include/precompiled/stdc++.h \
>       -o i586-msdosdjgpp/bits/stdc++.h.gch/O2ggnu++0x.gch
>
> Adding the `gcc/gcc/include` directory resolves the issue.
>
> My question is:
>
> Should the target GCC include directory (e.g. gcc/gcc/include or libgcc/include) be automatically added to the include path when building libstdc++ in a Canadian Cross environment?
>
> If not, is there a recommended or officially supported way to ensure that libstdc++ can see the target GCC headers during a Canadian Cross build, especially for platforms whose libc does not provide `max_align_t`?
>
> Thank you for your time. Any guidance on whether this is expected behavior or a configuration issue would be appreciated.
>
> Best regards