https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #19 from Bernd Edlinger <bernd.edlinger at hotmail dot de> --- (In reply to Jonathan Wakely from comment #18) > > Yes, I do have such targets. > > We use eCos at Softing as real time O/S a lot. > > Great, that's good to know. > > > I think I will build an ecos cross compiler, did so last year with > > gcc-5.1, (and had quite a lot of trouble with the bugs in > > ecos headers) > > > > ./gcc-5.1.0/configure --prefix=/home/ed/gnu/arm-eabi --target=arm-eabi > > --with-newlib --enable-languages=c,c++ --disable-hosted-libstdcxx > > --disable-__cxa-atexit --disable-libquadmath --disable-decimal-float > > Actually when I look closely, it used c_global but w/o hosted-libstdcxx: ed@w-ed:~/gnu/gcc-build-arm/arm-eabi/libstdc++-v3/include$ ls -ls cstddef 4 lrwxrwxrwx 1 ed ed 65 Feb 21 08:32 cstddef -> /home/ed/gnu/gcc-6-20160214/libs So at the moment I am not sure how to test the c/stddef. But I am sure that #define __need_offsetof can simply not work. I am not sure if it can compile at all, because if I try there are the same bogus symlinks to missing c/-headers. But before the build reaches the point where that matters, the cstdlib simply includes <stdlib.h> which fails to declare std::abort. Is this c/cstdlib intended for targets that have C++ aware stdlib.h? > > > > > > > #endif > > > > Index: c_global/cstddef > > > > =================================================================== > > > > --- c_global/cstddef (revision 233581) > > > > +++ c_global/cstddef (working copy) > > > > @@ -41,6 +41,11 @@ > > > > > > > > #pragma GCC system_header > > > > > > > > +#undef __need_wchar_t > > > > +#undef __need_size_t > > > > +#undef __need_ptrdiff_t > > > > +#undef __need_NULL > > > > +#undef __need_wint_t > > > > #include <bits/c++config.h> > > > > #include <stddef.h> > > > > > > This isn't incorrect, but it should not be necessary. This macros are > > > internal implementation details of the standard library headers, and user > > > code (like GMP) should not be defining those macros. If GMP wants size_t > > > it > > > should include <stddef.h> and if it wants std::size_t it should include > > > <cstddef>, and it should not try to play silly games to only get part of > > > the > > > header. > > > > > > > > > > Yeah, shit happens. > > Anyway boot-strap & reg-testing OK on x86_64-pc-linux-gnu. > > gcc-4.9 builds successfully (minus Ada, see pr69883 :() > > I'm in two minds whether we should fix that shit in the library or not. > When we leave it as it is, everyone will point with the finger on us, because it looks like a gcc-bug. Alternative would be to detect that any of the 6 known __need_-defines are present when invoking cstddef and give an explicit #error, but this mis-use worked previously. Or maybe a #warning would be a compromise? What do you think? > > For targets that choose to use it or with --enable-cheaders=c_std, but I > don't know of any targets where that is the default or needed, so don't know > how to test it. It is to be expected that you can't just use > --enable-cheaders=c_std on a target where that isn't usually used (and I'm > not surprised if those headers are also currently broken). > What I tried yesterday, that's probably worth fixing too. Bernd.