GCC fails on NetBSD 5.x because stddef.h assumes that machine/ansi.h defines _ANSI_H_ as its code guard. This prevents the definition of size_t.
Created attachment 16724 [details] Patch for stddef.h This patch ensures that _ANSI_H_ is defined after including machine/ansi.h.
I am seeing this on NetBSD 5.99.7, and can confirm that this prevents gcc from building at all on NetBSD 5.99.x. Is there any way this can get into 4.4.0? It is a very simple fix and applies cleanly.
Created attachment 17333 [details] Removes gcc's version of both stddef.h and sys/types.h This patch removes gcc's version of stddef.h and the "fixed" version of sys/types.h
Just hit this bug. Either solution looks good (am about to test, but spent ages reaching the same conclusion, so expect success for both) Anyone from gcc listening?
Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ The patch is obviously wrong (it changes the installed headers for all targets instead of setting USER_H to adjust the list for the target with this issue) and patches need to be submitted to gcc-patches following the instructions: http://gcc.gnu.org/contribute.html (which includes explaining the patch and how it fixes the problem).
(In reply to comment #5) > The patch is obviously wrong (it changes the installed headers for all > targets instead of setting USER_H to adjust the list for the target with > this issue) Care to explain more re USER_H? I tried to addIndex: stddef.h =================================================================== --- stddef.h (revision 145011) +++ stddef.h (working copy) @@ -62,6 +62,20 @@ #include <sys/_types.h> #endif +#if defined(__NetBSD__) +typedef _BSD_PTRDIFF_T_ ptrdiff_t; + +#ifdef _BSD_SIZE_T_ +typedef _BSD_SIZE_T_ size_t; +#undef _BSD_SIZE_T_ +#endif + +#ifdef _BSD_WCHAR_T_ +typedef _BSD_WCHAR_T_ wchar_t; +#undef _BSD_WCHAR_T_ +#endif +#endif /* __NetBSD__ */ + /* In 4.3bsd-net2, machine/ansi.h defines these symbols, which are defined if the corresponding type is *not* defined. FreeBSD-2.1 defines _MACHINE_ANSI_H_ instead of _ANSI_H_ */ which allowed me to compile gfortran. libsup++ failed including time.h, which behaved as though _BSD_SIZE_T_ was defined, but empty. Simply put, if I gcc -E gcc/gcc/ginclude/stddef.h, size_t is not defined: # 1 "stddef.h" # 1 "<built-in>" # 1 "<command line>" # 1 "stddef.h" # 58 "stddef.h" # 1 "/usr/include/machine/ansi.h" 1 3 4 # 37 "/usr/include/machine/ansi.h" 3 4 # 1 "/usr/include/sys/cdefs.h" 1 3 4 # 59 "/usr/include/sys/cdefs.h" 3 4 # 1 "/usr/include/machine/cdefs.h" 1 3 4 # 60 "/usr/include/sys/cdefs.h" 2 3 4 # 1 "/usr/include/sys/cdefs_elf.h" 1 3 4 # 62 "/usr/include/sys/cdefs.h" 2 3 4 # 38 "/usr/include/machine/ansi.h" 2 3 4 # 1 "/usr/include/machine/int_types.h" 1 3 4 # 45 "/usr/include/machine/int_types.h" 3 4 typedef signed char __int8_t; typedef unsigned char __uint8_t; typedef short int __int16_t; typedef unsigned short int __uint16_t; typedef int __int32_t; typedef unsigned int __uint32_t; typedef long long int __int64_t; typedef unsigned long long int __uint64_t; typedef int __intptr_t; typedef unsigned int __uintptr_t; # 40 "/usr/include/machine/ansi.h" 2 3 4 # 73 "/usr/include/machine/ansi.h" 3 4 typedef union { __int64_t __mbstateL; char __mbstate8[128]; } __mbstate_t; # 59 "stddef.h" 2 and machine/ansi.h defines _${MACHINE}_ANSI_H_ on NetBSD. If I gcc -E /usr/include/stddef.h, size_t is defined.
Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ On Mon, 23 Mar 2009, prlw1 at cam dot ac dot uk wrote: > ------- Comment #6 from prlw1 at cam dot ac dot uk 2009-03-23 20:45 ------- > (In reply to comment #5) > > The patch is obviously wrong (it changes the installed headers for all > > targets instead of setting USER_H to adjust the list for the target with > > this issue) > > Care to explain more re USER_H? I tried to addIndex: stddef.h USER_H is GCC's mechanism to disable installing some of the headers, such as stddef.h, that it installs by default. You're meant to set it in a target makefile fragment t-* instead of changing the global default definition in gcc/Makefile.in. Thus, if NetBSD should have all the GCC-provided headers except for stddef.h, copy the default from gcc/Makefile.in to gcc/config/t-netbsd and remove stddef.h there (with a comment to say that it's stddef.h that's being removed).
What about the first patch, which seems less drastic? (I think it would be better to install gcc's stddef.h, so there is one thing less to remember when upgrading gcc) It seems that if our machine/ansi.h defined _MACHINE_ANSI_H_ rather than _${MACHINE}_ANSI_H_, things would be happier. The first patch defines _ANSI_H_ instead. Hmm I'll try both and see...
Created attachment 17528 [details] Removes problematic fixincludes and defines _ANSI_H in stddef.h This is a combination of the other two patches. GCC's version of stddef.h is still installed and fixed for NetBSD. The copy of sys/types.h is not installed.
Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ On Tue, 24 Mar 2009, aran at 100acres dot us wrote: > This is a combination of the other two patches. GCC's version of stddef.h is > still installed and fixed for NetBSD. The copy of sys/types.h is not > installed. Once you have finished testing, please send the patch with ChangeLog entries and a self-contained explanation to gcc-patches as described in contribute.html. Do not include the diffs to the generated file fixincl.x; the person committing it will need to regenerate it using a current autogen version (which would keep GPLv3 notices there rather than wrongly substituting GPLv2 notices).
Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ I see you did in fact send the stddef.h changes to gcc-patches - thanks for splitting up the separate logical parts of the patch (which is always best to do, since the stddef.h and fixincludes changes can reasonably be reviewed separately).
Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ Joseph, The fixincludes changes fix another issue. Should I create a new bug and reference that bug in the e-mail or just describe the problem in the e-mail? Aran On Tuesday 24 March 2009 6:22:25 joseph at codesourcery dot com wrote: > ------- Comment #10 from joseph at codesourcery dot com > 2009-03-24 13:22 ------- Subject: Re: stddef.h assumes > machinee/ansi.h defines _ANSI_H_ > > On Tue, 24 Mar 2009, aran at 100acres dot us wrote: > > This is a combination of the other two patches. GCC's > > version of stddef.h is still installed and fixed for > > NetBSD. The copy of sys/types.h is not installed. > > Once you have finished testing, please send the patch > with ChangeLog entries and a self-contained explanation > to gcc-patches as described in contribute.html. > > Do not include the diffs to the generated file fixincl.x; > the person committing it will need to regenerate it using > a current autogen version (which would keep GPLv3 notices > there rather than wrongly substituting GPLv2 notices).
Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ On Tue, 24 Mar 2009, aran at 100acres dot us wrote: > Joseph, > The fixincludes changes fix another issue. Should I create > a new bug and reference that bug in the e-mail or just > describe the problem in the e-mail? Describing the problem in the email is sufficient. If the patch isn't reviewed within a week or so then ping it (as many times as needed). If the patch is approved but not committed, make clear that you need someone with write access to commit it for you.
I take it all is in hand, and I don't need to test anything? (I did a successful build with the same as the first patch, but defining _MACHINE_ANSI_H_ - this is equivalent - all went well)
I just got stuck with this again: wondered why a NetBSD-5.99.15/i386 box with gcc-HEAD wouldn't compile. Then remembered the #define _ANSI_H_ fix and all is well. What is impeding this patch from being applied?
Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ On Mon, 7 Sep 2009, prlw1 at cam dot ac dot uk wrote: > I just got stuck with this again: wondered why a NetBSD-5.99.15/i386 box with > gcc-HEAD wouldn't compile. Then remembered the #define _ANSI_H_ fix and all is > well. What is impeding this patch from being applied? I don't recall seeing weekly pings of it; presumably no maintainer in a relevant area picked up review of it the first and only time it was posted and noone made maintainers aware of the continued need for review by pinging it until it gets reviewed.
*** Bug 43952 has been marked as a duplicate of this bug. ***
(In reply to joseph@codesourcery.com from comment #16) > Subject: Re: stddef.h assumes machinee/ansi.h defines > _ANSI_H_ > > On Mon, 7 Sep 2009, prlw1 at cam dot ac dot uk wrote: > > > I just got stuck with this again: wondered why a NetBSD-5.99.15/i386 box with > > gcc-HEAD wouldn't compile. Then remembered the #define _ANSI_H_ fix and all is > > well. What is impeding this patch from being applied? > > I don't recall seeing weekly pings of it; presumably no maintainer in a > relevant area picked up review of it the first and only time it was posted > and noone made maintainers aware of the continued need for review by > pinging it until it gets reviewed. There been any new pings in the last 9 and a half years?
Is it even still an issue? I think NetBSD builds now.
r261797 removed all references to _ANSI_H_ from stddef.h, so this issue can't be relevant after then.
(In reply to joseph@codesourcery.com from comment #20) > r261797 removed all references to _ANSI_H_ from stddef.h, so this issue > can't be relevant after then. ...so that sounds like it can be closed, then.