On 2/12/21 11:30 AM, Jonathan Wakely wrote:
This patch is wrong.
Indeed, thanks for checking.
If you simply disable that function definition
for !__cpp_rtti then you'll get linker errors from fstream.tcc when
that function is called.
/usr/bin/ld:
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so:
undefined reference to `std::__throw_ios_failure(char const*, int)'
Funny enough that doesn't occur for my use case - builds fine. However
building with a toolchain for bare metal, potentially resulting in
disabling e.g. fstream.
This was done correctly for the c++98 part and probably just forgotten
for c++11.
This has nothing to do with C++98, it's relted to the gcc4-compatible
ABI versus the cxx11 ABI.
Urgs, yeah, that last chunk for cxx98 expands a different macro to
include that definition - not the rtti ifdef. Misread and wrongly took over.
I added a better patch to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99077
Thanks!
PS: Shouldn't this have been covered by any tests?
Nobody tests building libstdc++ with -fno-rtti because almost nobody
does that.
Just as info: Espressif's crosstool-ng fork (not sure about vanilla) is
building with no-rtti for targeting their Xtensa based ESP32 SoCs.
That's how I stumbled over this.
But we have plenty of tests, and hundreds of them fail with your patch
:-)
Yeah, glass houses and stones.. sorry for that :)
mirko
