On Tue, 11 Mar 2025 at 01:17, Dennis Clarke via Gcc-help <gcc-help@xxxxxxxxxxx> wrote: > > > This is just a strange situation that I know I have seen before and > really can not recall how to fix it. For that matter, I do not recall > what the problem really is. Let it be said that I have done a bootstrap > before a few times and I just _know_ this has happened before. With that > said I apologize if this is a "dummy you did that to yourself" question. > > After doing a bootstrap and test report with the new binutils 2.44 > and then GCC 14.2.0 on an IBM POWER9 machine and an x86_64 Xeon machine > I get strange behavior. However only on the x86_64 machine. Here is what > happens : > > triton$ uname -a > Linux triton 6.1.128-genunix #1 SMP Sun Mar 9 19:44:14 UTC 2025 x86_64 > GNU/Linux > triton$ > triton$ which gas > /opt/bw/bin/gas > triton$ gas --version > GNU assembler (GENUNIX Mon Mar 10 16:45:34 UTC 2025) 2.44 > Copyright (C) 2025 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or later. > This program has absolutely no warranty. > This assembler was configured for a target of `x86_64-pc-linux-gnu'. > triton$ > triton$ which g++ > /opt/bw/gcc14/bin/g++ > triton$ g++ --version > g++ (GENUNIX Mon Mar 10 18:16:45 UTC 2025) 14.2.0 > Copyright (C) 2024 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -v would be a lot more interesting and useful here than --version > * * * looks to be a good compiler * * * > see https://gcc.gnu.org/pipermail/gcc-testresults/2025-March/840512.html I'm curious why these are failing: FAIL: std/time/exceptions.cc -std=gnu++20 execution test FAIL: std/time/exceptions.cc -std=gnu++26 execution test FAIL: std/time/time_zone/get_info_local.cc -std=gnu++20 execution test FAIL: std/time/time_zone/get_info_local.cc -std=gnu++26 execution test FAIL: std/time/time_zone/get_info_sys.cc -std=gnu++20 execution test FAIL: std/time/time_zone/get_info_sys.cc -std=gnu++26 execution test FAIL: std/time/tzdb/1.cc -std=gnu++20 execution test FAIL: std/time/tzdb/1.cc -std=gnu++26 execution test FAIL: std/time/zoned_time/1.cc -std=gnu++20 execution test FAIL: std/time/zoned_time/1.cc -std=gnu++26 execution test FAIL: std/time/zoned_time/custom.cc -std=gnu++20 execution test FAIL: std/time/zoned_time/custom.cc -std=gnu++26 execution test FAIL: std/time/zoned_time/io.cc -std=gnu++20 execution test FAIL: std/time/zoned_time/io.cc -std=gnu++26 execution test FAIL: libstdc++-prettyprinters/chrono.cc execution test FAIL: libstdc++-prettyprinters/chrono.cc execution test > > > triton$ echo $CXXFLAGS > -std=c++11 -m64 -g -O0 -march=k8 -mtune=k8 -fno-builtin -fno-fast-math > -mpreferred-stack-boundary=8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags Why? If you're trying to debug something as basic as not finding the standard library headers, what are most of these flags doing here? You can get rid of all of these. > triton$ > triton$ echo $CPPFLAGS > -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 Why bother? You're on x86_64, right? Get rid of these. > triton$ > triton$ cat nothing.cpp > > #include <iostream> > > /* This test rejects OSF 5.1 Compaq C++ in its default pre-standard iostream > mode, since that mode puts cout in the global namespace, not "std". */ > void someoutput (void) { std::cout << 123; } > > int main (void) { return 0; } > triton$ > triton$ /opt/bw/gcc14/bin/g++ $CXXFLAGS $CPPFLAGS -c -o nothing.o > nothing.cpp > nothing.cpp:2:10: fatal error: iostream: No such file or directory > 2 | #include <iostream> > | ^~~~~~~~~~ > compilation terminated. Add -v and see where it's looking for the headers. Check if the headers are present there.
