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

[coshvji cujmlqef]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20260316/d1026523/attachment-0001.htm>