This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]