Re: Re: [committed] libstdc++: Allow Clang to use <stdatomic.h> before C++23

[Alexander Hans <ahans@neuralpropulsion.com>]

Hi,

Thanks for your prompt reply. Now things are much clearer!


> Then Bazel is broken. The assumption that "there are no name clashes
> between C++ and C header files" has never been true.

> I suppose we could support that silliness like this:
> [...]
> But I don't really like having to patch libstdc++ to support broken tools.

I agree that libstdc++ is not the right place to fix this. But thanks for the
patch in any case, that's better than my unconditional #else and I'll keep
it in mind. That would also allow me to work around the issue.

Regarding your question why this happens in the first place:

> Why does Bazel even need to know those directories? It should not be
> adding them for compiling C code nor for compiling C++ code, because
> GCC does that automatically (and gets it right).

Bazel can detect a local toolchain and use it. Then everything works as
expected. But it can also support some other toolchain, contained in some
archive you tell it to download from somewhere. I'm trying to integrate
gcc 12 via this route and do this based on some existing Bazel rules that are
pretty close to what I need [1]. They call gcc passing -nostdinc and giving
the include directories via -isystem arguments. However, some preliminary
testing suggests you should actually use only --sysroot for that and avoid
-nostdinc and any extra -isystem arguments. If that's true, the fix should
happen in the gcc toolchain-specific Bazel rules. The section I quoted
about the cxx_builtin_include_directories parameter and the assumption
that there are no name clashes is probably not an issue: I believe this
is only about telling Bazel where those files live, so that it can make them
available (Bazel is all about hermetic builds and to that end it wants to
know exactly what is used for the build). Using --sysroot, they will be
made available for C compilations as well, but ignored as you explained.
The only unclean part about this is that we cannot tell Bazel which
toolchain-supplied files a C-only build depends on (it will always be both,
C and C++ files), but that is acceptable.

Thanks again!

Alex

[1] https://github.com/aspect-build/gcc-toolchain