I'm only making an educated guess on the summary, based on this not being widespread, some apparent guards against this in g++ include files and how my upgrading path went. It might be triggered by other cases too, but this is how it went for me: An outdated system was upgraded to 2016 July state with glibc upgraded to 2.22-r4. As next batch updates were done to 2017-01-01 state, with glibc upgrade failing and thus skipped. GCC was 5.4.0 for these. Then as next step upgrades were done to current state (with tree at a bit before 9th Dec state while at toolchain and most things were rebuilt), with gcc 5.4->7.2.0, glibc 2.22-r4 -> 2.26-r3 and profile 13.0 -> 17.0 all in same go. GCC was upgraded, then profile switched and CFLAGS tunes, then libtool, binutils and glibc upgraded, then a world rebuild manually done, with gcc rebuild skipped. Technically this is different from what the news item proposed with a full rebuild, redoing gcc/glibc/libtool/binutils yet again - if the theory is right how I got into having errors, then this would have avoided it. But this is not important for upstream gcc issue case, I don't think. In this situation, I have firefox failing to compile with: In file included from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/ff/dist/system_wrappers/cmath:3:0, from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/ff/dist/stl_wrappers/cmath:44, from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/ff/dist/include/mozilla/MathAlgorithms.h:15, from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/ff/dist/include/nsTArray.h:18, from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/ff/dist/include/Intervals.h:12, from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/ff/dist/include/TimeUnits.h:10, from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/ff/dist/include/MediaData.h:12, from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/media/libstagefright/binding/Adts.cpp:6, from /tmp/portage/www-client/firefox-57.0.1/work/firefox-57.0.1/ff/media/libstagefright/Unified_cpp_media_libstagefright0.cpp:2: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include/g++-v7/cmath:596:11: error: '::isinf' has not been declared using ::isinf; ^~~~~ /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include/g++-v7/cmath:623:11: error: '::isnan' has not been declared using ::isnan; ^~~~~ (firefox ESR fails the same way). I see some guards/checks in bits/os_defines.h for g++, but seem to not work for cmath.
Created attachment 510326 [details] firefox build log
Does the error disappear if you rebuild gcc? I think it usually happens when you only upgrade glibc but not gcc. gcc usually detects at ./configure time what system headers provide to override or hide in C++ <c*> headers (like cmath or cstdint). https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/
Yes, firefox compiled so long I drifted off from this topic and didn't remember to report back before now. It compiled fine after gcc rebuild to build against the new glibc. It's suspect to me due to there being some apparent handling against it in bits/os_defines.h, but not for cmath.
Let's close as WONTFIX and require users to rebuild gcc.