gcc-12 and beyond provide support for the C++23 standard "include <stacktrace>" [1]. However, this feature must be enabled when GCC itself it built with the `--enable-libstdcxx-backtrace` flag [2]. Currently (2024-01-15) there is no USE flag in any GCC ebuild to enable this feature. I humbly ask that such a flag be added (at least for GCC 13 and 14). Without it, the `std::stacktrace` mechanism fails to compile in code that wants to use it (such as my own project). Passing `--enable-libstdcxx-backtrace` to configure when building GCC should result in the following changes: 1. The symbol `_GLIBCXX_HAVE_STACKTRACE` being defined in .../c++config.h [3] 2. The build and installation of the library `stdc++_libbacktrace` (until gcc14, then it is renamed [2, 4]). Thank you very much for your consideration. [1] https://en.cppreference.com/w/cpp/header/stacktrace [2] https://stackoverflow.com/a/72342952 [3] $ grep _GLIBCXX_HAVE_STACKTRACE /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/x86_64-pc-linux-gnu/bits/c++config.h /* #undef _GLIBCXX_HAVE_STACKTRACE */ [4] https://gcc.gnu.org/onlinedocs/libstdc++/manual/using.html#manual.intro.using.flags
oddly, this macro is set to 1 on my system. could you post gcc config logs?
Created attachment 883191 [details] All "config.log" files for "emerge =sys-devel/gcc-13.2.1_p20240113-r1"
Odd, it appears to be building libbacktrace though. But it did not get installed when I tried this 2 days ago. /var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/build/libbacktrace # ls -l *.o -rw-r--r-- 1 portage portage 960 Jan 26 10:10 atomic.o -rw-r--r-- 1 portage portage 2168 Jan 26 10:10 backtrace.o -rw-r--r-- 1 portage portage 39920 Jan 26 10:10 dwarf.o -rw-r--r-- 1 portage portage 52728 Jan 26 10:10 elf.o -rw-r--r-- 1 portage portage 3952 Jan 26 10:10 fileline.o -rw-r--r-- 1 portage portage 2248 Jan 26 10:10 mmapio.o -rw-r--r-- 1 portage portage 3720 Jan 26 10:10 mmap.o -rw-r--r-- 1 portage portage 2128 Jan 26 10:10 posix.o -rw-r--r-- 1 portage portage 2696 Jan 26 10:10 print.o -rw-r--r-- 1 portage portage 1880 Jan 26 10:10 simple.o -rw-r--r-- 1 portage portage 1856 Jan 26 10:10 sort.o -rw-r--r-- 1 portage portage 1592 Jan 26 10:10 state.o I'll re-run the emerge and see what happens (but I don't expect it to install the libstdc++backtrace.so, not set the symbol in c++config.h).
wait, what version of gcc before? I think I know what this is.
I do not understand your question. If you are asking what version of GCC I used to compile GCC? I have tried building gcc-13 with both gcc-11 (libbacktrace not installed) and gcc-13 (libbacktrace still not installed). I an redoing the emerge of gcc-13 using gcc-13 _right now_. It should finish in a few minutes. I can also hop onto IRC #gentoo and discuss there if that is a better method than posting near-real-time updates to this bug tracker.
Hm, I was thinking of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111936. The other thing that Fedora hit was specific to them (so not worth me mentioning).
emerge of gcc-13 (using gcc-13 as compiler) just finished: # grep _GLIBCXX_HAVE_STACKTRACE /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/x86_64-pc-linux-gnu/bits/c++config.h /* #undef _GLIBCXX_HAVE_STACKTRACE */ It is interesting that there is no "libstdc++.so" installed... # ls /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++* /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.a /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++exp.a /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++exp.la /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++fs.a /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so.6 /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so.6.0.32 The GCC docs say that "stdc++libbacktrace" will be folded into "libstdc++exp" in GCC-14, so I would be surprised to find the backtrace stuff there in gcc-13. # nm /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++exp.a | grep -i backtrace (no output)
I don't see the target-machine build directory logs (i.e. x86_64-pc-linux-gnu/libstdc++-v3 for instance) in the archive you posted. ah, sorry for the confusion - this macro is set on my system *for gcc-14*. I didn't pick up on this initially. can reproduce, then
