https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
--- Comment #28 from Arsen Arsenović <arsen at gcc dot gnu.org> --- (In reply to cqwrteur from comment #26) > > The c++ frontend has defined _GNU_Source since at least 2001. > > You are de facto, breaking abi without any good reason. You break > cross-compiling for linux distribution for even the last year. Glibc 2.34 > (which was just 3 years ago) removed -lpthread dependency. I would accept > glibc2.34 as a base. Then what about this __isoc99scanf that behaves > differently under different C and C++ standard. How is this code even > linkable? It easily becomes ODR violations. It does not become an ODR violation. Functions behave different in different languages (such as C99 vs. C23 vs. C++11). This is not unusual. > https://news.ycombinator.com/item?id=32471624 > > The problem is that unlike libstdc++, glibc is not upgradable. This is false. I upgraded glibc a few days ago. > Don't make any excuse tbh. If people are not happy with it, fix it. If you > give a > reason for breaking abi for a good reason i would accept that, but you don't > you just break abi for no reason. In this case, it is more like a bug for a > C standard feature where C++ standard does not support, at least not yet. No ABI was broken. > (In reply to Andrew Pinski from comment #25) > > _GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe others. > > > > > > The other issue is not a gcc issue but a build issue with not using a > > sysroot. > Except no matter i try with sysroot i does not really work out. Plus i am > building crossback compiler. It should not even care about sysroot. Why not? It has to pull libraries and headers from somewhere (note that I do not know what "crossback" means). Note that there is desire to not predefine _GNU_SOURCE in C++ modes. See the PRs Andrew referenced.
