clang - one warning may be a bit too excessive / too spammy, specifically "clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories"

**Title of this issue request:**

clang - one warning may be a bit too excessive / too spammy, specifically "clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories"

**Secondary title and request:**

Verbosity of the clang compiler - would it be possible to reduce the default verbosity or "gather" those verbose messages?

**Rationale:**

Hey there LLVM-devs,

I am using Linux and compiling from source, using some ruby scripts; a bit similar
to homebrew.

Usually I use GCC, but since some time already, I try to compile everything with clang by
default, just to see how much I can compile, as-is, compared to GCC. This works for
perhaps 99% of the software out there; for some other software there are issues and
problems, but in general it works really well. Hopefully we can all one day easily
compile everything via clang. \o/ (May try musl still, but for now, just glibc.)

I am not yet at the least LLVM version, due to some compile problem; I'll give this
another try this weekend or so. Right now I am using clang version clang version
22.1.0.

Now, I also use unusual directories. For instance, I default to /home/Programs/ as my
AppDir prefix, and something such as libdvdread-7.1.1, which I try to compile right
now, will go into this --prefix directory:

/home/Programs/Libdvdread/7.1.1/

And from there it will be symlinked, e. g. to /usr/bin/, /usr/lib/ and so forth.

Now, when I run "ninja" here, I get this output:

[1/13] Compiling C object src/libdvdread.so.8.2.0.p/logger.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[2/13] Compiling C object src/libdvdread.so.8.2.0.p/bitreader.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[3/13] Compiling C object src/libdvdread.so.8.2.0.p/file_file_posix.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[4/13] Compiling C object src/libdvdread.so.8.2.0.p/dvd_input.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[5/13] Compiling C object src/libdvdread.so.8.2.0.p/md5.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[6/13] Compiling C object src/libdvdread.so.8.2.0.p/nav_print.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[7/13] Compiling C object src/libdvdread.so.8.2.0.p/nav_read.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[8/13] Compiling C object src/libdvdread.so.8.2.0.p/dvd_udf.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[9/13] Compiling C object src/libdvdread.so.8.2.0.p/ifo_print.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]
[10/13] Compiling C object src/libdvdread.so.8.2.0.p/dvd_reader.c.o
clang warning: future releases of the clang compiler will prefer GCC installations containing libstdc++ include directories; '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0' [-Wgcc-install-dir-libstdcxx]

Literally at every line, clang shows this warning. I get it that this is
useful to know at the least once, but other than the first time, this is
really just ... spam. It does not give useful information to me past the
first time.

Would it be possible to reduce the number of warnings? For instance, it
would be neat if clang could count internally how often it showed this
warning already; at that first "ninja" step or "ninja install", it could
count, and if the count is more than once in that particular step, it
would not show the warning again. This would be a compromise between
the trade-off of you guys wanting to inform the user or developer that
clang will change (this is totally fine), and the trade-off that it
constantly spams this message on every iteration.

This is a low priority issue request though. If you guys don't want to
change anything then this is also fine, I'll add compensating code in
my ruby scripts to keep track of the counting, but before I do that I
wanted to give it a try to provide a rationale as to why the warning
output should be reduced. This also, by the way, happens without
compiling anything; when I issue "clang --version" I get this:

clang: warning: future releases of the clang compiler will prefer
GCC installations containing libstdc++ include directories;
'/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/16.1.0' would be
chosen over '/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/17.0.0'
[-Wgcc-install-dir-libstdcxx]

I have multiple different directories for GCC and it is not an issue
on my system, so clang warning me here is actually, IMO, bogus
anyway. I just so happen to have, for the time being, some GCC
versions also use /usr/ as prefix, in addition to /home/Programs/Gcc/ -
but I can manage all of this on my own. I am a bit surprised that
clang gets confused about it, because even with /usr/ as prefix,
it is totally clear which GCC version should be used anyway, so
I don't understand why clang is showing this warning. I'd have
both gcc 16.1.0 and gcc dev 17.0.0, and they do not use the
same directory under /usr/ (if we ignore /home/Programs/Gcc/ for
now), so it really is unclear why clang wants to complain - but
I have not yet tested this with more recent clang versions, so my
issue request about the actual compiling step, via "ninja", is
still valid.)

At any rate please do feel free to close this issue request at
any moment in time - LLVM has so many open issues that I totally
understand priorities assigned to more important things than
warning. Still I feel the current number of warnings are a bit
excessive.

Start by reproducing the warning with `clang --version` and the reported `ninja` build, focusing on `-Wgcc-install-dir-libstdcxx`. Determine whether the warning should be emitted once per command or otherwise grouped, and verify that the resulting output no longer repeats it for every compilation step.

Written by the indexing model from the issue text.