* FreeBSD 4.0 @ 1999-09-14 19:32 Wes Morgan 1999-09-14 20:08 ` Richard Henderson ` (2 more replies) 0 siblings, 3 replies; 107+ messages in thread From: Wes Morgan @ 1999-09-14 19:32 UTC (permalink / raw) To: gcc Trying to build the latest CVS snapshot under freebsd 4.0 fails with these errors: In file included from ../../egcs/gcc/libgcc2.c:1408: include/stdio.h:245: parse error before `__gnuc_va_list' include/stdio.h:246: parse error before `__gnuc_va_list' include/stdio.h:247: parse error before `__gnuc_va_list' include/stdio.h:311: parse error before `__gnuc_va_list' include/stdio.h:313: parse error before `__gnuc_va_list' include/stdio.h:315: parse error before `__gnuc_va_list' include/stdio.h:316: parse error before `__gnuc_va_list' include/stdio.h:346: parse error before `__gnuc_va_list' *** Error code 1 There are a few mentions of fixing _BSD_VA_LIST_ to __gnuc_va_list in some of the changelogs, but I haven't seen anything conclusive... Is this a known problem, or is my CVS tree out of sync somehow? Or maybe I need to set some different CFLAGS? WM -- The difference between genius and stupidity is that genius has its limits. Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 19:32 FreeBSD 4.0 Wes Morgan @ 1999-09-14 20:08 ` Richard Henderson 1999-09-15 2:00 ` Jeffrey A Law 1999-09-30 18:02 ` Richard Henderson 1999-09-14 22:34 ` Loren James Rittle 1999-09-30 18:02 ` Wes Morgan 2 siblings, 2 replies; 107+ messages in thread From: Richard Henderson @ 1999-09-14 20:08 UTC (permalink / raw) To: Wes Morgan; +Cc: gcc On Tue, Sep 14, 1999 at 10:33:00PM -0400, Wes Morgan wrote: > In file included from ../../egcs/gcc/libgcc2.c:1408: > include/stdio.h:245: parse error before `__gnuc_va_list' I just checked in a much simplified version of stdarg.h. Would you send me a preprocessed copy and we can figure out what went wrong. r~ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 20:08 ` Richard Henderson @ 1999-09-15 2:00 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Richard Henderson 1 sibling, 1 reply; 107+ messages in thread From: Jeffrey A Law @ 1999-09-15 2:00 UTC (permalink / raw) To: Richard Henderson; +Cc: Wes Morgan In message < 19990914200826.A7982@cygnus.com >you write: > On Tue, Sep 14, 1999 at 10:33:00PM -0400, Wes Morgan wrote: > > In file included from ../../egcs/gcc/libgcc2.c:1408: > > include/stdio.h:245: parse error before `__gnuc_va_list' > > I just checked in a much simplified version of stdarg.h. > Would you send me a preprocessed copy and we can figure > out what went wrong. > I believe this problem pre-dates the va-* reorg. We've got to get the stddef.h and fixinc stuff for freebsd re-reviewed and deal with the remaining issues. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 2:00 ` Jeffrey A Law @ 1999-09-30 18:02 ` Jeffrey A Law 0 siblings, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: Richard Henderson; +Cc: Wes Morgan, gcc In message < 19990914200826.A7982@cygnus.com >you write: > On Tue, Sep 14, 1999 at 10:33:00PM -0400, Wes Morgan wrote: > > In file included from ../../egcs/gcc/libgcc2.c:1408: > > include/stdio.h:245: parse error before `__gnuc_va_list' > > I just checked in a much simplified version of stdarg.h. > Would you send me a preprocessed copy and we can figure > out what went wrong. > I believe this problem pre-dates the va-* reorg. We've got to get the stddef.h and fixinc stuff for freebsd re-reviewed and deal with the remaining issues. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 20:08 ` Richard Henderson 1999-09-15 2:00 ` Jeffrey A Law @ 1999-09-30 18:02 ` Richard Henderson 1 sibling, 0 replies; 107+ messages in thread From: Richard Henderson @ 1999-09-30 18:02 UTC (permalink / raw) To: Wes Morgan; +Cc: gcc On Tue, Sep 14, 1999 at 10:33:00PM -0400, Wes Morgan wrote: > In file included from ../../egcs/gcc/libgcc2.c:1408: > include/stdio.h:245: parse error before `__gnuc_va_list' I just checked in a much simplified version of stdarg.h. Would you send me a preprocessed copy and we can figure out what went wrong. r~ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 19:32 FreeBSD 4.0 Wes Morgan 1999-09-14 20:08 ` Richard Henderson @ 1999-09-14 22:34 ` Loren James Rittle 1999-09-14 23:00 ` Zack Weinberg ` (2 more replies) 1999-09-30 18:02 ` Wes Morgan 2 siblings, 3 replies; 107+ messages in thread From: Loren James Rittle @ 1999-09-14 22:34 UTC (permalink / raw) To: morganw; +Cc: rth Wes Morgan wrote: > Trying to build the latest CVS snapshot under freebsd 4.0 fails with these > errors: ... > include/stdio.h:245: parse error before `__gnuc_va_list' ... > There are a few mentions of fixing _BSD_VA_LIST_ to __gnuc_va_list in some > of the changelogs, but I haven't seen anything conclusive... Is this a > known problem, or is my CVS tree out of sync somehow? Or maybe I need to > set some different CFLAGS? I have built gcc_ss_19990913 on FreeBSD 3.2-RELEASE with the patches in http://egcs.cygnus.com/ml/gcc-patches/1999-08/msg00728.html (they have been *REQUIRED* on FreeBSD for some time). The issue is that ports may no longer override USER_T in order to keep fixinc from running. Richard Henderson wrote: > I just checked in a much simplified version of stdarg.h. > Would you send me a preprocessed copy and we can figure > out what went wrong. Cool! If you have upgraded past gcc_ss_19990913 and picked up Richard's latest changes, then I can now confirm (since I just finished a bootstrap on the mainline with his changes) that the gcc/ginclude/stdarg.h and gcc/ginclude/varargs.h patches are no longer needed (since he removed the code that those patches affected ;-)! Unfortunately (although extremely minor), that means that until I get around to investigating the root issue in fixinc, any C++ code that relies on system headers which use _BSD_VA_LIST_ instead of va_list (not including stdio.h which is now correctly fixed) will fail with errors of this form: cannot convert `void *' to `char *' for argument `X' to `foo(...)' Richard, is it your position that all system headers must be fixed to only reference __gnuc_va_list instead of va_list and/or system-specific macros such as _BSD_VA_LIST_ (as was historically used by BSD systems)? If so, then fixinc's rule to mung _BSD_VA_LIST_ into __gnuc_va_list must be expanded to operate on 10-15 other standard BSD system headers... Wes, if you could tell me if the referenced patches work for you under FreeBSD 4.0, that could be helpful. Regards, Loren ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 22:34 ` Loren James Rittle @ 1999-09-14 23:00 ` Zack Weinberg 1999-09-14 23:14 ` David O'Brien ` (2 more replies) 1999-09-15 7:42 ` Wes Morgan 1999-09-30 18:02 ` Loren James Rittle 2 siblings, 3 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-14 23:00 UTC (permalink / raw) To: rittle; +Cc: morganw Loren James Rittle wrote: > > Unfortunately (although extremely minor), that means that until I get > around to investigating the root issue in fixinc, any C++ code that > relies on system headers which use _BSD_VA_LIST_ instead of va_list > (not including stdio.h which is now correctly fixed) will fail with > errors of this form: > > cannot convert `void *' to `char *' for argument `X' to `foo(...)' > > Richard, is it your position that all system headers must be fixed to > only reference __gnuc_va_list instead of va_list and/or > system-specific macros such as _BSD_VA_LIST_ (as was historically used > by BSD systems)? If so, then fixinc's rule to mung _BSD_VA_LIST_ into > __gnuc_va_list must be expanded to operate on 10-15 other standard BSD > system headers... May I suggest that stdarg.h/varargs.h be modified to #define _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to limit it to FreeBSD? (Is this needed by Net/OpenBSD too?) This is simpler and less fragile than adding stuff to fixinc. For complicated reasons related to similar interactions with glibc's headers, I'd personally like to see the typedef name be __va_list, and __gnuc_va_list a #define as well. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 23:00 ` Zack Weinberg @ 1999-09-14 23:14 ` David O'Brien 1999-09-15 0:25 ` Zack Weinberg ` (2 more replies) 1999-09-15 1:59 ` Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 3 replies; 107+ messages in thread From: David O'Brien @ 1999-09-14 23:14 UTC (permalink / raw) To: Zack Weinberg; +Cc: rittle > May I suggest that stdarg.h/varargs.h be modified to #define > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to > limit it to FreeBSD? Why not do it the other way around? #define __gnuc_va_list _BSD_VA_LIST_ Please, please lets not require the dinking of many system headers. Please also remember GCC is the base compiler in BSD and the number of things that have to be changed when native'ifing the compiler the better. > (Is this needed by Net/OpenBSD too?) This is simpler and less fragile > than adding stuff to fixinc. This is a 4.4BSD thing. It thus affects all of BSD. > For complicated reasons related to similar interactions with glibc's > headers, I'd personally like to see the typedef name be __va_list, and > __gnuc_va_list a #define as well. Can you explain these interactions? I really doubt the BSD headers are as intertwined. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 23:14 ` David O'Brien @ 1999-09-15 0:25 ` Zack Weinberg 1999-09-15 0:56 ` David O'Brien ` (2 more replies) 1999-09-15 2:00 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 2 siblings, 3 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-15 0:25 UTC (permalink / raw) To: obrien; +Cc: rittle "David O'Brien" wrote: > > May I suggest that stdarg.h/varargs.h be modified to #define > > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to > > limit it to FreeBSD? > > Why not do it the other way around? > > #define __gnuc_va_list _BSD_VA_LIST_ Because the "real" type is __gnuc_va_list. Doing it your way won't do what you want. I hope you don't have system headers that typedef _BSD_VA_LIST_ without reference to gcc's stdarg.h - for one thing, we probably just irrevocably broke them. > Please, please lets not require the dinking of many system headers. > Please also remember GCC is the base compiler in BSD and the number of > things that have to be changed when native'ifing the compiler the better. I believe #define _BSD_VA_LIST_ __gnuc_va_list will solve your problem without any dinking of BSD libc headers. > > (Is this needed by Net/OpenBSD too?) This is simpler and less fragile > > than adding stuff to fixinc. > > This is a 4.4BSD thing. It thus affects all of BSD. Is there any macro which is defined by all 4.4-derived systems? > > For complicated reasons related to similar interactions with glibc's > > headers, I'd personally like to see the typedef name be __va_list, and > > __gnuc_va_list a #define as well. > > Can you explain these interactions? I really doubt the BSD headers are > as intertwined. The intertwining with glibc is not as bad as you might think, and __gnuc_va_list is actually the least bad part. For real issues, try to figure out what wint_t is doing in stddef.h, or how limits.h works. The problem with __gnuc_va_list is primarily aesthetic. Everyone has to agree on the underlying typedef name because of C++ mangled names. Therefore I would like the underlying typedef name to be compiler-neutral. People do want to use glibc with compilers other than gcc. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 0:25 ` Zack Weinberg @ 1999-09-15 0:56 ` David O'Brien 1999-09-15 1:21 ` Andreas Schwab 1999-09-30 18:02 ` David O'Brien 1999-09-15 1:17 ` David O'Brien 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 2 replies; 107+ messages in thread From: David O'Brien @ 1999-09-15 0:56 UTC (permalink / raw) To: Zack Weinberg; +Cc: obrien > Is there any macro which is defined by all 4.4-derived systems? #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif to detect if the code is being compiled on a 4.3 Net2 code base or newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and below). #if (defined(BSD) && (BSD >= 199103)) to detect if the code is being compiled on a 4.4 code base or newer (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above). #if (defined(BSD) && (BSD >= 199306)) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 0:56 ` David O'Brien @ 1999-09-15 1:21 ` Andreas Schwab 1999-09-15 1:40 ` David O'Brien 1999-09-30 18:02 ` Andreas Schwab 1999-09-30 18:02 ` David O'Brien 1 sibling, 2 replies; 107+ messages in thread From: Andreas Schwab @ 1999-09-15 1:21 UTC (permalink / raw) To: obrien; +Cc: Zack Weinberg [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1039 bytes --] "David O'Brien" <obrien@NUXI.com> writes: |> > Is there any macro which is defined by all 4.4-derived systems? |> |> #if (defined(__unix__) || defined(unix)) && !defined(USG) ^^^^ ^^^ |> #include <sys/param.h> |> #endif |> |> to detect if the code is being compiled on a 4.3 Net2 code base or |> newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and |> below). |> |> #if (defined(BSD) && (BSD >= 199103)) ^^^ ^^^ |> |> to detect if the code is being compiled on a 4.4 code base or newer |> (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above). |> |> #if (defined(BSD) && (BSD >= 199306)) ^^^ ^^^ GCC cannot use any of the marked identifiers because they are in the application's namespace. Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:21 ` Andreas Schwab @ 1999-09-15 1:40 ` David O'Brien 1999-09-15 2:23 ` Andreas Schwab ` (2 more replies) 1999-09-30 18:02 ` Andreas Schwab 1 sibling, 3 replies; 107+ messages in thread From: David O'Brien @ 1999-09-15 1:40 UTC (permalink / raw) To: Andreas Schwab; +Cc: Zack Weinberg > |> #if (defined(__unix__) || defined(unix)) && !defined(USG) > ^^^^ ^^^ > |> #include <sys/param.h> /* :-) */ #include "config.h" #ifdef HAVE_PARAM_H #include <sys/param.h> #endif > |> #if (defined(BSD) && (BSD >= 199306)) > ^^^ ^^^ > > GCC cannot use any of the marked identifiers because they are in the > application's namespace. Reguardless, "BSD" is the approved way under BSD. If an application tries to define it, they will typically have problems compiling under BSD. Anyway GCC already uses symbols in the applications namespace: find . -type f | xargs grep 'f i386' ./gcc/libgcc2.c:#ifdef i386 ./gcc/config/i386/xm-i386.h:#ifndef i386 -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:40 ` David O'Brien @ 1999-09-15 2:23 ` Andreas Schwab 1999-09-15 3:11 ` David O'Brien 1999-09-30 18:02 ` Andreas Schwab 1999-09-20 3:58 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 2 siblings, 2 replies; 107+ messages in thread From: Andreas Schwab @ 1999-09-15 2:23 UTC (permalink / raw) To: obrien; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 695 bytes --] "David O'Brien" <obrien@NUXI.com> writes: |> > |> #if (defined(__unix__) || defined(unix)) && !defined(USG) |> > ^^^^ ^^^ |> > |> #include <sys/param.h> |> |> /* :-) */ |> #include "config.h" |> #ifdef HAVE_PARAM_H |> #include <sys/param.h> |> #endif We cannot use an config header in <stdarg.h>. This header must be absolutely namespace clean. If you don't know what that means please read the C standard. Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 2:23 ` Andreas Schwab @ 1999-09-15 3:11 ` David O'Brien 1999-09-15 3:52 ` Andreas Schwab 1999-09-30 18:02 ` David O'Brien 1999-09-30 18:02 ` Andreas Schwab 1 sibling, 2 replies; 107+ messages in thread From: David O'Brien @ 1999-09-15 3:11 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1090 bytes --] Andreas, I'm sorry I don't know who you are (I guess I should go check the GCC web pages...) but pleaes butt out. Zack Weinberg <zack@bitmover.com> asked if there was any macro that all 4.4BSD-derived systems defined. I answered it. > We cannot use an config header in <stdarg.h>. No shit. Be a software engineer and engineer. Have gcc-x.y/configure do what ever way you want of including <sys/param.h> and testing for "BSD". Then have it spit out "__44BSD_INSIDE", and have whatever later script do or extract what ever Zack may want to do. > This header must be absolutely namespace clean. If you don't know what > that means please read the C standard. Yes I know what this means. > Andreas Schwab "And now for something > schwab@suse.de completely different." > SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg IMHO, you are not being helpful in this discussion, and since you probably know more about non-BSD hosts than BSD hosts why are you speaking out here?? -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 3:11 ` David O'Brien @ 1999-09-15 3:52 ` Andreas Schwab 1999-09-30 18:02 ` Andreas Schwab 1999-09-30 18:02 ` David O'Brien 1 sibling, 1 reply; 107+ messages in thread From: Andreas Schwab @ 1999-09-15 3:52 UTC (permalink / raw) To: obrien; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 836 bytes --] "David O'Brien" <obrien@NUXI.com> writes: |> Andreas, |> |> I'm sorry I don't know who you are (I guess I should go check the GCC web |> pages...) but pleaes butt out. |> |> Zack Weinberg <zack@bitmover.com> asked if there was any macro that all |> 4.4BSD-derived systems defined. I answered it. Please don't take this personal, but unfortunately your answer wasn't appropriate in the context of a conforming C implementation. The <stdarg.h> and <stdlib.h> headers are very different from the files in gcc source. It is important to keep this distinction in mind, otherwise the -ansi flags does not deserve its name. Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 3:52 ` Andreas Schwab @ 1999-09-30 18:02 ` Andreas Schwab 0 siblings, 0 replies; 107+ messages in thread From: Andreas Schwab @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 836 bytes --] "David O'Brien" <obrien@NUXI.com> writes: |> Andreas, |> |> I'm sorry I don't know who you are (I guess I should go check the GCC web |> pages...) but pleaes butt out. |> |> Zack Weinberg <zack@bitmover.com> asked if there was any macro that all |> 4.4BSD-derived systems defined. I answered it. Please don't take this personal, but unfortunately your answer wasn't appropriate in the context of a conforming C implementation. The <stdarg.h> and <stdlib.h> headers are very different from the files in gcc source. It is important to keep this distinction in mind, otherwise the -ansi flags does not deserve its name. Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 3:11 ` David O'Brien 1999-09-15 3:52 ` Andreas Schwab @ 1999-09-30 18:02 ` David O'Brien 1 sibling, 0 replies; 107+ messages in thread From: David O'Brien @ 1999-09-30 18:02 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1090 bytes --] Andreas, I'm sorry I don't know who you are (I guess I should go check the GCC web pages...) but pleaes butt out. Zack Weinberg <zack@bitmover.com> asked if there was any macro that all 4.4BSD-derived systems defined. I answered it. > We cannot use an config header in <stdarg.h>. No shit. Be a software engineer and engineer. Have gcc-x.y/configure do what ever way you want of including <sys/param.h> and testing for "BSD". Then have it spit out "__44BSD_INSIDE", and have whatever later script do or extract what ever Zack may want to do. > This header must be absolutely namespace clean. If you don't know what > that means please read the C standard. Yes I know what this means. > Andreas Schwab "And now for something > schwab@suse.de completely different." > SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg IMHO, you are not being helpful in this discussion, and since you probably know more about non-BSD hosts than BSD hosts why are you speaking out here?? -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 2:23 ` Andreas Schwab 1999-09-15 3:11 ` David O'Brien @ 1999-09-30 18:02 ` Andreas Schwab 1 sibling, 0 replies; 107+ messages in thread From: Andreas Schwab @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 695 bytes --] "David O'Brien" <obrien@NUXI.com> writes: |> > |> #if (defined(__unix__) || defined(unix)) && !defined(USG) |> > ^^^^ ^^^ |> > |> #include <sys/param.h> |> |> /* :-) */ |> #include "config.h" |> #ifdef HAVE_PARAM_H |> #include <sys/param.h> |> #endif We cannot use an config header in <stdarg.h>. This header must be absolutely namespace clean. If you don't know what that means please read the C standard. Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:40 ` David O'Brien 1999-09-15 2:23 ` Andreas Schwab @ 1999-09-20 3:58 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 2 siblings, 1 reply; 107+ messages in thread From: Jeffrey A Law @ 1999-09-20 3:58 UTC (permalink / raw) To: obrien; +Cc: Andreas Schwab, Zack Weinberg, rittle, morganw, rth, gcc, pfeifer In message < 19990915013954.D17808@dragon.nuxi.com >you write: > Anyway GCC already uses symbols in the applications namespace: > > find . -type f | xargs grep 'f i386' > ./gcc/libgcc2.c:#ifdef i386 > ./gcc/config/i386/xm-i386.h:#ifndef i386 Just because gcc already does something that is wrong, does not mean we should add new stuff that is also clearly wrong. GCC has a lot of baggage from it's past; we're trying to kill those things which are clearly wrong and stupid as time permits. If you want to be helpful submit a patch to change those to __i386__. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 3:58 ` Jeffrey A Law @ 1999-09-30 18:02 ` Jeffrey A Law 0 siblings, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: Andreas Schwab, Zack Weinberg, rittle, morganw, rth, gcc, pfeifer In message < 19990915013954.D17808@dragon.nuxi.com >you write: > Anyway GCC already uses symbols in the applications namespace: > > find . -type f | xargs grep 'f i386' > ./gcc/libgcc2.c:#ifdef i386 > ./gcc/config/i386/xm-i386.h:#ifndef i386 Just because gcc already does something that is wrong, does not mean we should add new stuff that is also clearly wrong. GCC has a lot of baggage from it's past; we're trying to kill those things which are clearly wrong and stupid as time permits. If you want to be helpful submit a patch to change those to __i386__. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:40 ` David O'Brien 1999-09-15 2:23 ` Andreas Schwab 1999-09-20 3:58 ` Jeffrey A Law @ 1999-09-30 18:02 ` David O'Brien 2 siblings, 0 replies; 107+ messages in thread From: David O'Brien @ 1999-09-30 18:02 UTC (permalink / raw) To: Andreas Schwab; +Cc: Zack Weinberg, rittle, morganw, rth, gcc, pfeifer > |> #if (defined(__unix__) || defined(unix)) && !defined(USG) > ^^^^ ^^^ > |> #include <sys/param.h> /* :-) */ #include "config.h" #ifdef HAVE_PARAM_H #include <sys/param.h> #endif > |> #if (defined(BSD) && (BSD >= 199306)) > ^^^ ^^^ > > GCC cannot use any of the marked identifiers because they are in the > application's namespace. Reguardless, "BSD" is the approved way under BSD. If an application tries to define it, they will typically have problems compiling under BSD. Anyway GCC already uses symbols in the applications namespace: find . -type f | xargs grep 'f i386' ./gcc/libgcc2.c:#ifdef i386 ./gcc/config/i386/xm-i386.h:#ifndef i386 -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:21 ` Andreas Schwab 1999-09-15 1:40 ` David O'Brien @ 1999-09-30 18:02 ` Andreas Schwab 1 sibling, 0 replies; 107+ messages in thread From: Andreas Schwab @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: Zack Weinberg, rittle, morganw, rth, gcc, pfeifer [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1039 bytes --] "David O'Brien" <obrien@NUXI.com> writes: |> > Is there any macro which is defined by all 4.4-derived systems? |> |> #if (defined(__unix__) || defined(unix)) && !defined(USG) ^^^^ ^^^ |> #include <sys/param.h> |> #endif |> |> to detect if the code is being compiled on a 4.3 Net2 code base or |> newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and |> below). |> |> #if (defined(BSD) && (BSD >= 199103)) ^^^ ^^^ |> |> to detect if the code is being compiled on a 4.4 code base or newer |> (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above). |> |> #if (defined(BSD) && (BSD >= 199306)) ^^^ ^^^ GCC cannot use any of the marked identifiers because they are in the application's namespace. Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 0:56 ` David O'Brien 1999-09-15 1:21 ` Andreas Schwab @ 1999-09-30 18:02 ` David O'Brien 1 sibling, 0 replies; 107+ messages in thread From: David O'Brien @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: obrien, rittle, morganw, rth, gcc, pfeifer > Is there any macro which is defined by all 4.4-derived systems? #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif to detect if the code is being compiled on a 4.3 Net2 code base or newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and below). #if (defined(BSD) && (BSD >= 199103)) to detect if the code is being compiled on a 4.4 code base or newer (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above). #if (defined(BSD) && (BSD >= 199306)) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 0:25 ` Zack Weinberg 1999-09-15 0:56 ` David O'Brien @ 1999-09-15 1:17 ` David O'Brien 1999-09-15 9:23 ` Zack Weinberg ` (2 more replies) 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 3 replies; 107+ messages in thread From: David O'Brien @ 1999-09-15 1:17 UTC (permalink / raw) To: Zack Weinberg; +Cc: rittle > Because the "real" type is __gnuc_va_list. Doing it your way won't do > what you want. I hope you don't have system headers that typedef > _BSD_VA_LIST_ without reference to gcc's stdarg.h - from /usr/include/machine/ansi.h #define _BSD_VA_LIST_ char * /* va_list */ There are no GCC headers in my base system. We've never needed them, and there are copyright issues anyway. > for one thing, we probably just irrevocably broke them. That is not good. (doesn't anyone there have access to a BSD machine??) > The problem with __gnuc_va_list is primarily aesthetic. If it is only aesthetics then lets leave it alone. > Everyone has to agree on the underlying typedef name because of C++ > mangled names. Therefore I would like the underlying typedef name to > be compiler-neutral. If you want g++ compiled by someone under FreeBSD to work with the base compiler, libs etc. the type will need to be _BSD_VA_LIST_ (char *). > People do want to use glibc with compilers other than gcc. I don't care what other people do with glibc. -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:17 ` David O'Brien @ 1999-09-15 9:23 ` Zack Weinberg 1999-09-15 10:24 ` David O'Brien ` (2 more replies) 1999-09-20 4:34 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 2 siblings, 3 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-15 9:23 UTC (permalink / raw) To: obrien; +Cc: rittle "David O'Brien" wrote: > > Because the "real" type is __gnuc_va_list. Doing it your way won't do > > what you want. I hope you don't have system headers that typedef > > _BSD_VA_LIST_ without reference to gcc's stdarg.h - > > from /usr/include/machine/ansi.h > > #define _BSD_VA_LIST_ char * /* va_list */ > > There are no GCC headers in my base system. We've never needed them, and > there are copyright issues anyway. Do you have your own stdarg.h too? This definition will not work with the new stdarg scheme. gcc's stdarg.h does #ifndef __GNUC_VA_LIST #define __GNUC_VA_LIST typedef __builtin_va_list __gnuc_va_list; #endif __builtin_va_list is an opaque type which may be 'char *' deep inside, but won't be compatible in the C sense with 'char *'. Since it's a #define not a typedef, we can work around it: #ifdef _BSD_VA_LIST_ #undef _BSD_VA_LIST_ #define _BSD_VA_LIST_ __gnuc_va_list #endif but that requires us to get machine/ansi.h included by stdarg.h. Since that header is BSD specific, we go back to needing some automatically defined macro that can be tested. And I'm sorry, but Andreas is right, we cannot use 'BSD'. Suppose stdarg.h is the very first header included by a user program. Only the macros predefined by the compiler are available, and those don't include BSD. (It has nothing to do with -ansi.) gcc's stddef.h has the same problem and is using /* On 4.3bsd-net2, make sure ansi.h is included, so we have one less case to deal with in the following. */ #if defined __BSD_NET2__ || defined ____386BSD____ \ || defined __FreeBSD__ || defined __NetBSD__ #include <machine/ansi.h> #endif which looks pretty safe modulo the absence of __OpenBSD__... I'd like to know what machine/ansi.h does on Alphas, where "char *" doesn't work for va_list. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 9:23 ` Zack Weinberg @ 1999-09-15 10:24 ` David O'Brien 1999-09-16 14:48 ` Richard Henderson 1999-09-30 18:02 ` David O'Brien 1999-09-20 4:20 ` Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 2 replies; 107+ messages in thread From: David O'Brien @ 1999-09-15 10:24 UTC (permalink / raw) To: Zack Weinberg; +Cc: rittle > > There are no GCC headers in my base system. We've never needed them, and > > there are copyright issues anyway. > > Do you have your own stdarg.h too? Yes. Both /usr/include/stdarg.h and /usr/include/machine/stdarg.h, they are identical files. The following are from the 4.0 development branch. i386 version: typedef char *va_list; #define __va_size(type) \ (((sizeof(type) + sizeof(int) - 1) / sizeof(int)) * sizeof(int)) #ifdef __GNUC__ #define va_start(ap, last) \ ((ap) = (va_list)__builtin_next_arg(last)) #else #define va_start(ap, last) \ ((ap) = (va_list)&(last) + __va_size(last)) #endif #define va_arg(ap, type) \ (*(type *)((ap) += __va_size(type), (ap) - __va_size(type))) #define va_end(ap) Alpha version: #include <machine/ansi.h> #ifdef __lint__ #define __builtin_saveregs() (0) #define __builtin_classify_type(t) (0) #endif typedef _BSD_VA_LIST_ va_list; #define __va_size(type) \ (((sizeof(type) + sizeof(long) - 1) / sizeof(long)) * sizeof(long)) #define va_start(ap, last) \ (__builtin_next_arg(last), (ap) = *(va_list *)__builtin_saveregs(), (ap).__pad = 0) #define __REAL_TYPE_CLASS 8 #define __va_arg_offset(ap, type) \ ((__builtin_classify_type(*(type *)0) == __REAL_TYPE_CLASS && \ (ap).__offset <= (6 * 8) ? -(6 * 8) : 0) - __va_size(type)) #define va_arg(ap, type) \ (*(type *)((ap).__offset += __va_size(type), \ (ap).__base + (ap).__offset + __va_arg_offset(ap, type))) #define va_end(ap) ((void)0) > but that requires us to get machine/ansi.h included by stdarg.h. > Since that header is BSD specific, we go back to needing some > automatically defined macro that can be tested. And I'm sorry, but > Andreas is right, we cannot use 'BSD'. Yes, I offered testing for "BSD" as something configure or any fix includes scripts could do and so _something_inserted_here_ to deal with the issue. > #if defined __BSD_NET2__ || defined ____386BSD____ \ > || defined __FreeBSD__ || defined __NetBSD__ > #include <machine/ansi.h> > #endif Yes, those are the only compiler/cpp defines you can be guarenteed of. > which looks pretty safe modulo the absence of __OpenBSD__... > > I'd like to know what machine/ansi.h does on Alphas, where "char *" > doesn't work for va_list. typedef struct { char *__base; int __offset; int __pad; } __va_list; #define _BSD_VA_LIST_ __va_list /* va_list */ -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 10:24 ` David O'Brien @ 1999-09-16 14:48 ` Richard Henderson 1999-09-30 18:02 ` Richard Henderson 1999-09-30 18:02 ` David O'Brien 1 sibling, 1 reply; 107+ messages in thread From: Richard Henderson @ 1999-09-16 14:48 UTC (permalink / raw) To: David O'Brien; +Cc: Zack Weinberg On Wed, Sep 15, 1999 at 10:24:03AM -0700, David O'Brien wrote: > #define va_start(ap, last) \ > (__builtin_next_arg(last), \ > (ap) = *(va_list *)__builtin_saveregs(), (ap).__pad = 0) This won't work any longer, for multiple reasons, either on Alpha or with any other target that passes arguments in registers in the presence of varargs. One of the changes actually fixes bugs that show up under rare conditions, so backward compatibility with old varargs headers isn't an option. Bottom line, with version 2.96 and later, you absolutely must use the builtins. Which means to me that you should just use gcc's stdarg.h always. r~ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 14:48 ` Richard Henderson @ 1999-09-30 18:02 ` Richard Henderson 0 siblings, 0 replies; 107+ messages in thread From: Richard Henderson @ 1999-09-30 18:02 UTC (permalink / raw) To: David O'Brien; +Cc: Zack Weinberg, rittle, gcc On Wed, Sep 15, 1999 at 10:24:03AM -0700, David O'Brien wrote: > #define va_start(ap, last) \ > (__builtin_next_arg(last), \ > (ap) = *(va_list *)__builtin_saveregs(), (ap).__pad = 0) This won't work any longer, for multiple reasons, either on Alpha or with any other target that passes arguments in registers in the presence of varargs. One of the changes actually fixes bugs that show up under rare conditions, so backward compatibility with old varargs headers isn't an option. Bottom line, with version 2.96 and later, you absolutely must use the builtins. Which means to me that you should just use gcc's stdarg.h always. r~ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 10:24 ` David O'Brien 1999-09-16 14:48 ` Richard Henderson @ 1999-09-30 18:02 ` David O'Brien 1 sibling, 0 replies; 107+ messages in thread From: David O'Brien @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: rittle, gcc > > There are no GCC headers in my base system. We've never needed them, and > > there are copyright issues anyway. > > Do you have your own stdarg.h too? Yes. Both /usr/include/stdarg.h and /usr/include/machine/stdarg.h, they are identical files. The following are from the 4.0 development branch. i386 version: typedef char *va_list; #define __va_size(type) \ (((sizeof(type) + sizeof(int) - 1) / sizeof(int)) * sizeof(int)) #ifdef __GNUC__ #define va_start(ap, last) \ ((ap) = (va_list)__builtin_next_arg(last)) #else #define va_start(ap, last) \ ((ap) = (va_list)&(last) + __va_size(last)) #endif #define va_arg(ap, type) \ (*(type *)((ap) += __va_size(type), (ap) - __va_size(type))) #define va_end(ap) Alpha version: #include <machine/ansi.h> #ifdef __lint__ #define __builtin_saveregs() (0) #define __builtin_classify_type(t) (0) #endif typedef _BSD_VA_LIST_ va_list; #define __va_size(type) \ (((sizeof(type) + sizeof(long) - 1) / sizeof(long)) * sizeof(long)) #define va_start(ap, last) \ (__builtin_next_arg(last), (ap) = *(va_list *)__builtin_saveregs(), (ap).__pad = 0) #define __REAL_TYPE_CLASS 8 #define __va_arg_offset(ap, type) \ ((__builtin_classify_type(*(type *)0) == __REAL_TYPE_CLASS && \ (ap).__offset <= (6 * 8) ? -(6 * 8) : 0) - __va_size(type)) #define va_arg(ap, type) \ (*(type *)((ap).__offset += __va_size(type), \ (ap).__base + (ap).__offset + __va_arg_offset(ap, type))) #define va_end(ap) ((void)0) > but that requires us to get machine/ansi.h included by stdarg.h. > Since that header is BSD specific, we go back to needing some > automatically defined macro that can be tested. And I'm sorry, but > Andreas is right, we cannot use 'BSD'. Yes, I offered testing for "BSD" as something configure or any fix includes scripts could do and so _something_inserted_here_ to deal with the issue. > #if defined __BSD_NET2__ || defined ____386BSD____ \ > || defined __FreeBSD__ || defined __NetBSD__ > #include <machine/ansi.h> > #endif Yes, those are the only compiler/cpp defines you can be guarenteed of. > which looks pretty safe modulo the absence of __OpenBSD__... > > I'd like to know what machine/ansi.h does on Alphas, where "char *" > doesn't work for va_list. typedef struct { char *__base; int __offset; int __pad; } __va_list; #define _BSD_VA_LIST_ __va_list /* va_list */ -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 9:23 ` Zack Weinberg 1999-09-15 10:24 ` David O'Brien @ 1999-09-20 4:20 ` Jeffrey A Law 1999-09-21 6:33 ` The USER_H issue Marc Espie 1999-09-30 18:02 ` FreeBSD 4.0 Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 2 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-20 4:20 UTC (permalink / raw) To: Zack Weinberg; +Cc: obrien, rittle, morganw, rth, gcc, pfeifer In message < 199909151623.JAA02391@zack.bitmover.com >you write: > > There are no GCC headers in my base system. We've never needed them, and > > there are copyright issues anyway. > > Do you have your own stdarg.h too? They may have their own stdarg.h, but we should not be using it. We should be using the gcc supplied stdarg.h & varargs.h. This is related to the who thread about how a port should never, ever override USER_H. Actually, given the revamp of the varargs/stdarg stuff recently, now might be as good a time as any to zap the USER_H overrides and arrange that they can not come back since ports which are redefining USER_H probably don't work right now anyway. That will also root out problems with stddef.h since ports like FreeBSD, OpenBSD and NetBSD will start using the one provided by gcc instead of their own. stddef.h has the header file that eventually sent me down the path of redefining USER_H years ago. FWIW, I believe the particular problem I was working around has already been fixed. The effected ports would be: ./alpha/t-interix:USER_H=$(LANG_EXTRA_HEADERS) ./pa/x-pa:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./i386/t-interix:USER_H=$(LANG_EXTRA_HEADERS) ./i386/x-dgux:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./m88k/x-dgux:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./m88k/x-dguxbcs:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./mips/x-netbsd:USER_H = $(srcdir)/ginclude/stdarg.h $(srcdir)/ginclude/varargs.h \ ./t-freebsd:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./t-openbsd:USER_H = ${LANG_EXTRA_HEADERS} And winnt I believe. [ For those wondering about x-pa, that is for PAs running 4.3/4.4 BSD, not the widely more available hpux :-) ] jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* The USER_H issue 1999-09-20 4:20 ` Jeffrey A Law @ 1999-09-21 6:33 ` Marc Espie 1999-09-30 18:02 ` Marc Espie 1999-09-30 18:02 ` FreeBSD 4.0 Jeffrey A Law 1 sibling, 1 reply; 107+ messages in thread From: Marc Espie @ 1999-09-21 6:33 UTC (permalink / raw) To: law; +Cc: egcs In article < 564.937826241@upchuck.cygnus.com > you write: > In message < 199909151623.JAA02391@zack.bitmover.com >you write: > > > There are no GCC headers in my base system. We've never needed them, and > > > there are copyright issues anyway. > > Do you have your own stdarg.h too? >They may have their own stdarg.h, but we should not be using it. We should >be using the gcc supplied stdarg.h & varargs.h. This is related to the who >thread about how a port should never, ever override USER_H. I'm sorry, but you keep saying overriding USER_H is wrong, even for distributors, and I keep telling you that we will end up with two distinct sets of headers, one for the system proper, and another `special' one for gcc. As far as the OpenBSD project is concerned, this is more efficient for us to rely on our own headers, and tweak the system installation so that those get used and debugged, instead of having two separate compilers with distinct sets of bugs... Please do tell me what's in it for us to remove the USER_H overrides. I understand that this means simpler maintenance for the gcc project, but it looks like it only has drawbacks for the OpenBSD project as far as maintenance is concerned: we just get those `generic' headers with hundreds of tweaks that don't apply to us, we will probably get some hard to debug interaction bugs at some point. It really looks simpler and more robust to just rely on our own headers and make sure those work. Not to say you can convince me, but you will have to use real, logical arguments, something more convincing than `overriding USER_H is wrong'. ^ permalink raw reply [flat|nested] 107+ messages in thread
* The USER_H issue 1999-09-21 6:33 ` The USER_H issue Marc Espie @ 1999-09-30 18:02 ` Marc Espie 0 siblings, 0 replies; 107+ messages in thread From: Marc Espie @ 1999-09-30 18:02 UTC (permalink / raw) To: law; +Cc: egcs In article < 564.937826241@upchuck.cygnus.com > you write: > In message < 199909151623.JAA02391@zack.bitmover.com >you write: > > > There are no GCC headers in my base system. We've never needed them, and > > > there are copyright issues anyway. > > Do you have your own stdarg.h too? >They may have their own stdarg.h, but we should not be using it. We should >be using the gcc supplied stdarg.h & varargs.h. This is related to the who >thread about how a port should never, ever override USER_H. I'm sorry, but you keep saying overriding USER_H is wrong, even for distributors, and I keep telling you that we will end up with two distinct sets of headers, one for the system proper, and another `special' one for gcc. As far as the OpenBSD project is concerned, this is more efficient for us to rely on our own headers, and tweak the system installation so that those get used and debugged, instead of having two separate compilers with distinct sets of bugs... Please do tell me what's in it for us to remove the USER_H overrides. I understand that this means simpler maintenance for the gcc project, but it looks like it only has drawbacks for the OpenBSD project as far as maintenance is concerned: we just get those `generic' headers with hundreds of tweaks that don't apply to us, we will probably get some hard to debug interaction bugs at some point. It really looks simpler and more robust to just rely on our own headers and make sure those work. Not to say you can convince me, but you will have to use real, logical arguments, something more convincing than `overriding USER_H is wrong'. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 4:20 ` Jeffrey A Law 1999-09-21 6:33 ` The USER_H issue Marc Espie @ 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: obrien, rittle, morganw, rth, gcc, pfeifer In message < 199909151623.JAA02391@zack.bitmover.com >you write: > > There are no GCC headers in my base system. We've never needed them, and > > there are copyright issues anyway. > > Do you have your own stdarg.h too? They may have their own stdarg.h, but we should not be using it. We should be using the gcc supplied stdarg.h & varargs.h. This is related to the who thread about how a port should never, ever override USER_H. Actually, given the revamp of the varargs/stdarg stuff recently, now might be as good a time as any to zap the USER_H overrides and arrange that they can not come back since ports which are redefining USER_H probably don't work right now anyway. That will also root out problems with stddef.h since ports like FreeBSD, OpenBSD and NetBSD will start using the one provided by gcc instead of their own. stddef.h has the header file that eventually sent me down the path of redefining USER_H years ago. FWIW, I believe the particular problem I was working around has already been fixed. The effected ports would be: ./alpha/t-interix:USER_H=$(LANG_EXTRA_HEADERS) ./pa/x-pa:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./i386/t-interix:USER_H=$(LANG_EXTRA_HEADERS) ./i386/x-dgux:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./m88k/x-dgux:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./m88k/x-dguxbcs:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./mips/x-netbsd:USER_H = $(srcdir)/ginclude/stdarg.h $(srcdir)/ginclude/varargs.h \ ./t-freebsd:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS) ./t-openbsd:USER_H = ${LANG_EXTRA_HEADERS} And winnt I believe. [ For those wondering about x-pa, that is for PAs running 4.3/4.4 BSD, not the widely more available hpux :-) ] jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 9:23 ` Zack Weinberg 1999-09-15 10:24 ` David O'Brien 1999-09-20 4:20 ` Jeffrey A Law @ 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 0 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: rittle, morganw, rth, gcc, pfeifer "David O'Brien" wrote: > > Because the "real" type is __gnuc_va_list. Doing it your way won't do > > what you want. I hope you don't have system headers that typedef > > _BSD_VA_LIST_ without reference to gcc's stdarg.h - > > from /usr/include/machine/ansi.h > > #define _BSD_VA_LIST_ char * /* va_list */ > > There are no GCC headers in my base system. We've never needed them, and > there are copyright issues anyway. Do you have your own stdarg.h too? This definition will not work with the new stdarg scheme. gcc's stdarg.h does #ifndef __GNUC_VA_LIST #define __GNUC_VA_LIST typedef __builtin_va_list __gnuc_va_list; #endif __builtin_va_list is an opaque type which may be 'char *' deep inside, but won't be compatible in the C sense with 'char *'. Since it's a #define not a typedef, we can work around it: #ifdef _BSD_VA_LIST_ #undef _BSD_VA_LIST_ #define _BSD_VA_LIST_ __gnuc_va_list #endif but that requires us to get machine/ansi.h included by stdarg.h. Since that header is BSD specific, we go back to needing some automatically defined macro that can be tested. And I'm sorry, but Andreas is right, we cannot use 'BSD'. Suppose stdarg.h is the very first header included by a user program. Only the macros predefined by the compiler are available, and those don't include BSD. (It has nothing to do with -ansi.) gcc's stddef.h has the same problem and is using /* On 4.3bsd-net2, make sure ansi.h is included, so we have one less case to deal with in the following. */ #if defined __BSD_NET2__ || defined ____386BSD____ \ || defined __FreeBSD__ || defined __NetBSD__ #include <machine/ansi.h> #endif which looks pretty safe modulo the absence of __OpenBSD__... I'd like to know what machine/ansi.h does on Alphas, where "char *" doesn't work for va_list. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:17 ` David O'Brien 1999-09-15 9:23 ` Zack Weinberg @ 1999-09-20 4:34 ` Jeffrey A Law 1999-09-20 9:26 ` Zack Weinberg 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 2 siblings, 2 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-20 4:34 UTC (permalink / raw) To: obrien; +Cc: Zack Weinberg, rittle, morganw, rth, gcc, pfeifer In message < 19990915011710.B25121@relay.nuxi.com >you write: > There are no GCC headers in my base system. We've never needed them, and > there are copyright issues anyway. What copyright issues? jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 4:34 ` Jeffrey A Law @ 1999-09-20 9:26 ` Zack Weinberg 1999-09-20 9:55 ` Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 2 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-20 9:26 UTC (permalink / raw) To: law; +Cc: obrien, rittle, morganw, rth, gcc, pfeifer Jeffrey A Law wrote: > In message < 19990915011710.B25121@relay.nuxi.com >you write: > > There are no GCC headers in my base system. We've never needed them, and > > there are copyright issues anyway. > What copyright issues? There is no explicit license/copyright statement at the top of stddef.h or stdarg.h or whatever. Someone could easily have been misled into thinking that they were GPLed and would infect programs. We should probably put something like the libstdc++ "special exception" paragraph at the top. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 9:26 ` Zack Weinberg @ 1999-09-20 9:55 ` Jeffrey A Law 1999-09-20 10:17 ` Zack Weinberg 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 1 sibling, 2 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-20 9:55 UTC (permalink / raw) To: Zack Weinberg; +Cc: obrien, rittle, morganw, rth, gcc, pfeifer In message < 199909201624.JAA16030@zack.bitmover.com >you write: > Jeffrey A Law wrote: > > In message < 19990915011710.B25121@relay.nuxi.com >you write: > > > There are no GCC headers in my base system. We've never needed them, > and > > > there are copyright issues anyway. > > What copyright issues? > > There is no explicit license/copyright statement at the top of > stddef.h or stdarg.h or whatever. Someone could easily have been > misled into thinking that they were GPLed and would infect programs. > > We should probably put something like the libstdc++ "special > exception" paragraph at the top. Sigh. There are times when the laxness of the previous 10 years really bugs me. This is one of them. Start with the template in libgcc2.c and change it to deal with header files instead of libraries. Do you want to do this, or should I (or if someone else wants it, speak up). jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 9:55 ` Jeffrey A Law @ 1999-09-20 10:17 ` Zack Weinberg 1999-09-20 10:38 ` Richard Earnshaw ` (2 more replies) 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 3 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-20 10:17 UTC (permalink / raw) To: law; +Cc: gcc, gcc-patches Jeffrey A Law wrote: > In message < 199909201624.JAA16030@zack.bitmover.com >you write: > > Jeffrey A Law wrote: > > > In message < 19990915011710.B25121@relay.nuxi.com >you write: > > > > There are no GCC headers in my base system. We've never needed the > m, > > and > > > > there are copyright issues anyway. > > > What copyright issues? > > > > There is no explicit license/copyright statement at the top of > > stddef.h or stdarg.h or whatever. Someone could easily have been > > misled into thinking that they were GPLed and would infect programs. > > > > We should probably put something like the libstdc++ "special > > exception" paragraph at the top. > Sigh. There are times when the laxness of the previous 10 years really > bugs me. This is one of them. > > Start with the template in libgcc2.c and change it to deal with header > files instead of libraries. > > Do you want to do this, or should I (or if someone else wants it, speak up). Patch appended. We still have to deal with float.h and limits.h which are generated. I personally think we should dump those files, but that's a larger issue. zw 1999-09-20 10:13 -0700 Zack Weinberg <zack@bitmover.com> * iso646.h, stdarg.h, stdbool.h, stddef.h, varargs.h: Add copyright notice and special exception to GPL. =================================================================== Index: iso646.h --- iso646.h 1998/12/16 21:19:18 1.2 +++ iso646.h 1999/09/20 17:11:58 @@ -1,5 +1,36 @@ -/* Macros for C programs written in national variants of ISO 646. */ +/* Copyright (C) 1997, 1999 Free Software Foundation, Inc. +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ + +/* + * ISO C Standard: 7.9 Alternative spellings <iso646.h> + */ + +#ifndef _ISO646_H +#define _ISO646_H + #ifndef __cplusplus #define and && #define and_eq &= @@ -12,4 +43,6 @@ #define or_eq |= #define xor ^ #define xor_eq ^= +#endif + #endif =================================================================== Index: stdarg.h --- stdarg.h 1999/09/14 23:30:44 1.10 +++ stdarg.h 1999/09/20 17:11:58 @@ -1,9 +1,33 @@ -/* stdarg.h for GNU. +/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc. - Note that the type used in va_arg is supposed to match the - actual type **after default promotions**. - Thus, va_arg (..., short) is not valid. */ +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ + +/* + * ISO C Standard: 7.15 Variable arguments <stdarg.h> + */ + #ifndef _STDARG_H #ifndef _ANSI_STDARG_H_ #ifndef __need___va_list @@ -22,6 +46,10 @@ typedef __builtin_va_list __gnuc_va_list /* Define the standard macros for the user, if this invocation was from the user program. */ #ifdef _STDARG_H + +/* Note that the type used in va_arg is supposed to match the + actual type **after default promotions**. + Thus, va_arg (..., short) is not valid. */ #define va_start(v,l) __builtin_stdarg_start(&(v),l) #define va_end __builtin_va_end =================================================================== Index: stdbool.h --- stdbool.h 1999/08/29 15:46:14 1.3 +++ stdbool.h 1999/09/20 17:11:58 @@ -1,6 +1,35 @@ -/* stdbool.h for GNU. */ -#ifndef __STDBOOL_H__ -#define __STDBOOL_H__ 1 +/* Copyright (C) 1998, 1999 Free Software Foundation, Inc. + +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ + +/* + * ISO C Standard: 7.16 Boolean type and values <stdbool.h> + */ + +#ifndef _STDBOOL_H +#define _STDBOOL_H /* The type `_Bool' must promote to `int' or `unsigned int'. The constants `true' and `false' must have the value 0 and 1 respectively. */ =================================================================== Index: stddef.h --- stddef.h 1998/12/16 21:19:25 1.4 +++ stddef.h 1999/09/20 17:11:58 @@ -1,3 +1,32 @@ +/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc. + +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ + +/* + * ISO C Standard: 7.17 Common definitions <stddef.h> + */ #if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \ && !defined(__STDDEF_H__)) \ || defined(__need_wchar_t) || defined(__need_size_t) \ =================================================================== Index: varargs.h --- varargs.h 1999/09/14 23:30:44 1.12 +++ varargs.h 1999/09/20 17:11:58 @@ -1,4 +1,28 @@ -/* Record that this is varargs.h; this turns off stdarg.h. */ +/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc. + +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ #ifndef _VARARGS_H #define _VARARGS_H ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 10:17 ` Zack Weinberg @ 1999-09-20 10:38 ` Richard Earnshaw 1999-09-20 11:02 ` Zack Weinberg ` (2 more replies) 1999-09-23 8:51 ` Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 3 replies; 107+ messages in thread From: Richard Earnshaw @ 1999-09-20 10:38 UTC (permalink / raw) To: Zack Weinberg; +Cc: richard.earnshaw > Start with the template in libgcc2.c and change it to deal with header > files instead of libraries. > But what if I want to pass my code through lint? I've now got to find another set of header files to replace these or I risk bringing my own code under the GPL (the special exemption clause only applies if I'm using the header for compiling with GCC). OK, I guess I'm probably still better off than I was before (when technically, since there was no usage statement, I probably had no rights to use the file at all), but this may still be a problem in a BSD system. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 10:38 ` Richard Earnshaw @ 1999-09-20 11:02 ` Zack Weinberg 1999-09-30 18:02 ` Zack Weinberg 1999-09-20 11:39 ` Horst von Brand 1999-09-30 18:02 ` Richard Earnshaw 2 siblings, 1 reply; 107+ messages in thread From: Zack Weinberg @ 1999-09-20 11:02 UTC (permalink / raw) To: richard.earnshaw; +Cc: law, gcc, gcc-patches Richard Earnshaw wrote: > > > Start with the template in libgcc2.c and change it to deal with header > > files instead of libraries. > > > > But what if I want to pass my code through lint? I've now got to find > another set of header files to replace these or I risk bringing my own > code under the GPL (the special exemption clause only applies if I'm using > the header for compiling with GCC). lint doesn't generate an executable, so you're fine. You'd have a problem if you were to use the header in conjunction with a different *compiler*, such as lcc - but I believe our position is that lcc needs to provide its own copies of these headers anyway. I'd be fine with generalizing the special exception to any compiler, but that's not for me to decide. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 11:02 ` Zack Weinberg @ 1999-09-30 18:02 ` Zack Weinberg 0 siblings, 0 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-30 18:02 UTC (permalink / raw) To: richard.earnshaw; +Cc: law, gcc, gcc-patches Richard Earnshaw wrote: > > > Start with the template in libgcc2.c and change it to deal with header > > files instead of libraries. > > > > But what if I want to pass my code through lint? I've now got to find > another set of header files to replace these or I risk bringing my own > code under the GPL (the special exemption clause only applies if I'm using > the header for compiling with GCC). lint doesn't generate an executable, so you're fine. You'd have a problem if you were to use the header in conjunction with a different *compiler*, such as lcc - but I believe our position is that lcc needs to provide its own copies of these headers anyway. I'd be fine with generalizing the special exception to any compiler, but that's not for me to decide. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 10:38 ` Richard Earnshaw 1999-09-20 11:02 ` Zack Weinberg @ 1999-09-20 11:39 ` Horst von Brand 1999-09-20 11:49 ` Chris G. Demetriou 1999-09-30 18:02 ` Horst von Brand 1999-09-30 18:02 ` Richard Earnshaw 2 siblings, 2 replies; 107+ messages in thread From: Horst von Brand @ 1999-09-20 11:39 UTC (permalink / raw) To: richard.earnshaw; +Cc: Zack Weinberg, law, gcc Richard Earnshaw <rearnsha@arm.com> said: > > Start with the template in libgcc2.c and change it to deal with header > > files instead of libraries. > But what if I want to pass my code through lint? I've now got to find > another set of header files to replace these or I risk bringing my own > code under the GPL (the special exemption clause only applies if I'm using > the header for compiling with GCC). AFAIU, if you pass the code + headers through <whatever> (<whatever> != gcc), you have to abide by the GPL with the output. I.e., _if_ you distribute it further, you _must_ provide sources. I suspect you don't want to distribute lint output... BTW, this again leaves a gray area for files that are first preprocessed somehow, for example with something like Oracle's Pro*C that handles SQL embedded in C/C++, giving C/C++ files that are then compiled. AFAIR, Pro*C _does_ #include files when preprocessing. IANAL, just a satisfied GNU software user. -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 11:39 ` Horst von Brand @ 1999-09-20 11:49 ` Chris G. Demetriou 1999-09-30 18:02 ` Chris G. Demetriou 1999-09-30 18:02 ` Horst von Brand 1 sibling, 1 reply; 107+ messages in thread From: Chris G. Demetriou @ 1999-09-20 11:49 UTC (permalink / raw) To: Horst von Brand; +Cc: richard.earnshaw, Zack Weinberg, law, gcc Horst von Brand <vonbrand@inf.utfsm.cl> writes: > I suspect you don't want > to distribute lint output... In fact, he may. For instance, say you build a lint library (llib-lfoo.ln) for distribution. (Say you're making an SDK for some proprietary software, and want to include a lint library so that people can lint their code?) NetBSD, for instance, ships lint libraries for all of the system libraries. It's reasonable to expect a vendor of an SDK to want to do the same... cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 11:49 ` Chris G. Demetriou @ 1999-09-30 18:02 ` Chris G. Demetriou 0 siblings, 0 replies; 107+ messages in thread From: Chris G. Demetriou @ 1999-09-30 18:02 UTC (permalink / raw) To: Horst von Brand; +Cc: richard.earnshaw, Zack Weinberg, law, gcc Horst von Brand <vonbrand@inf.utfsm.cl> writes: > I suspect you don't want > to distribute lint output... In fact, he may. For instance, say you build a lint library (llib-lfoo.ln) for distribution. (Say you're making an SDK for some proprietary software, and want to include a lint library so that people can lint their code?) NetBSD, for instance, ships lint libraries for all of the system libraries. It's reasonable to expect a vendor of an SDK to want to do the same... cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 11:39 ` Horst von Brand 1999-09-20 11:49 ` Chris G. Demetriou @ 1999-09-30 18:02 ` Horst von Brand 1 sibling, 0 replies; 107+ messages in thread From: Horst von Brand @ 1999-09-30 18:02 UTC (permalink / raw) To: richard.earnshaw; +Cc: Zack Weinberg, law, gcc Richard Earnshaw <rearnsha@arm.com> said: > > Start with the template in libgcc2.c and change it to deal with header > > files instead of libraries. > But what if I want to pass my code through lint? I've now got to find > another set of header files to replace these or I risk bringing my own > code under the GPL (the special exemption clause only applies if I'm using > the header for compiling with GCC). AFAIU, if you pass the code + headers through <whatever> (<whatever> != gcc), you have to abide by the GPL with the output. I.e., _if_ you distribute it further, you _must_ provide sources. I suspect you don't want to distribute lint output... BTW, this again leaves a gray area for files that are first preprocessed somehow, for example with something like Oracle's Pro*C that handles SQL embedded in C/C++, giving C/C++ files that are then compiled. AFAIR, Pro*C _does_ #include files when preprocessing. IANAL, just a satisfied GNU software user. -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 10:38 ` Richard Earnshaw 1999-09-20 11:02 ` Zack Weinberg 1999-09-20 11:39 ` Horst von Brand @ 1999-09-30 18:02 ` Richard Earnshaw 2 siblings, 0 replies; 107+ messages in thread From: Richard Earnshaw @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: richard.earnshaw > Start with the template in libgcc2.c and change it to deal with header > files instead of libraries. > But what if I want to pass my code through lint? I've now got to find another set of header files to replace these or I risk bringing my own code under the GPL (the special exemption clause only applies if I'm using the header for compiling with GCC). OK, I guess I'm probably still better off than I was before (when technically, since there was no usage statement, I probably had no rights to use the file at all), but this may still be a problem in a BSD system. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 10:17 ` Zack Weinberg 1999-09-20 10:38 ` Richard Earnshaw @ 1999-09-23 8:51 ` Jeffrey A Law 1999-09-23 9:13 ` Pending Projects Bruce Korb 1999-09-30 18:02 ` FreeBSD 4.0 Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 2 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-23 8:51 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc, gcc-patches In message < 199909201715.KAA17676@zack.bitmover.com >you write: > > Sigh. There are times when the laxness of the previous 10 years really > > bugs me. This is one of them. > > > > Start with the template in libgcc2.c and change it to deal with header > > files instead of libraries. > > > > Do you want to do this, or should I (or if someone else wants it, speak u > p). > > Patch appended. > > We still have to deal with float.h and limits.h which are generated. > I personally think we should dump those files, but that's a larger > issue. > > zw > > 1999-09-20 10:13 -0700 Zack Weinberg <zack@bitmover.com> > > * iso646.h, stdarg.h, stdbool.h, stddef.h, varargs.h: Add > copyright notice and special exception to GPL. Approved. Note that float.h and limits.h are generated from source files within gcc itself, so we can easily add the right copyright to them. As for deleting them, let's take that up later. We've got enough major projects in progress already (and queued) that I'd like to see finished before we do something like deleting those files. Thanks, jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Pending Projects 1999-09-23 8:51 ` Jeffrey A Law @ 1999-09-23 9:13 ` Bruce Korb 1999-09-30 18:02 ` Bruce Korb 1999-09-30 18:02 ` FreeBSD 4.0 Jeffrey A Law 1 sibling, 1 reply; 107+ messages in thread From: Bruce Korb @ 1999-09-23 9:13 UTC (permalink / raw) To: law; +Cc: gcc, gcc-patches, korb Jeffrey A Law wrote: > As for deleting [float.h and limits.h], let's take that up later. > We've got enough major projects in progress already ... Speaking of which, I have that "no_bogosity" thread in fixinc that I would like to turn on. I have nailed all the blockages to removing the silly grandfather process (if you remember it), and have added support for writing C routines for testing and applying fixes. This is very useful for the "//" elimination fix. :-) In a couple of weeks, I would like to do the following: 1. Replace gcc/fixincludes with the current version of gcc/fixinc/inclhack.sh 2. Remove the old-method commentary from gcc/Makefile.in 3. Merge the no_bogosity path into the main line It features the following: a) *Three* binaries are produced - fixincl (as today, but with specially coded fixes and fix application tests - and no grandfather process) - fixtests - run from within the new inclhack.sh takes two arguments: a file name and test name - fixfixes - takes *one* argument: a fix name processes stdin to stdout b) named tests and fixes can be added as C code to fixtests.c and fixfixes.c, respectively. Both are included in the fixincl binary. c) Replacement text fixes simplify the "wrapper" method. (I.e., the file is never massaged. The text is simply written out.) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Pending Projects 1999-09-23 9:13 ` Pending Projects Bruce Korb @ 1999-09-30 18:02 ` Bruce Korb 0 siblings, 0 replies; 107+ messages in thread From: Bruce Korb @ 1999-09-30 18:02 UTC (permalink / raw) To: law; +Cc: gcc, gcc-patches, korb Jeffrey A Law wrote: > As for deleting [float.h and limits.h], let's take that up later. > We've got enough major projects in progress already ... Speaking of which, I have that "no_bogosity" thread in fixinc that I would like to turn on. I have nailed all the blockages to removing the silly grandfather process (if you remember it), and have added support for writing C routines for testing and applying fixes. This is very useful for the "//" elimination fix. :-) In a couple of weeks, I would like to do the following: 1. Replace gcc/fixincludes with the current version of gcc/fixinc/inclhack.sh 2. Remove the old-method commentary from gcc/Makefile.in 3. Merge the no_bogosity path into the main line It features the following: a) *Three* binaries are produced - fixincl (as today, but with specially coded fixes and fix application tests - and no grandfather process) - fixtests - run from within the new inclhack.sh takes two arguments: a file name and test name - fixfixes - takes *one* argument: a fix name processes stdin to stdout b) named tests and fixes can be added as C code to fixtests.c and fixfixes.c, respectively. Both are included in the fixincl binary. c) Replacement text fixes simplify the "wrapper" method. (I.e., the file is never massaged. The text is simply written out.) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-23 8:51 ` Jeffrey A Law 1999-09-23 9:13 ` Pending Projects Bruce Korb @ 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc, gcc-patches In message < 199909201715.KAA17676@zack.bitmover.com >you write: > > Sigh. There are times when the laxness of the previous 10 years really > > bugs me. This is one of them. > > > > Start with the template in libgcc2.c and change it to deal with header > > files instead of libraries. > > > > Do you want to do this, or should I (or if someone else wants it, speak u > p). > > Patch appended. > > We still have to deal with float.h and limits.h which are generated. > I personally think we should dump those files, but that's a larger > issue. > > zw > > 1999-09-20 10:13 -0700 Zack Weinberg <zack@bitmover.com> > > * iso646.h, stdarg.h, stdbool.h, stddef.h, varargs.h: Add > copyright notice and special exception to GPL. Approved. Note that float.h and limits.h are generated from source files within gcc itself, so we can easily add the right copyright to them. As for deleting them, let's take that up later. We've got enough major projects in progress already (and queued) that I'd like to see finished before we do something like deleting those files. Thanks, jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 10:17 ` Zack Weinberg 1999-09-20 10:38 ` Richard Earnshaw 1999-09-23 8:51 ` Jeffrey A Law @ 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 0 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-30 18:02 UTC (permalink / raw) To: law; +Cc: gcc, gcc-patches Jeffrey A Law wrote: > In message < 199909201624.JAA16030@zack.bitmover.com >you write: > > Jeffrey A Law wrote: > > > In message < 19990915011710.B25121@relay.nuxi.com >you write: > > > > There are no GCC headers in my base system. We've never needed the > m, > > and > > > > there are copyright issues anyway. > > > What copyright issues? > > > > There is no explicit license/copyright statement at the top of > > stddef.h or stdarg.h or whatever. Someone could easily have been > > misled into thinking that they were GPLed and would infect programs. > > > > We should probably put something like the libstdc++ "special > > exception" paragraph at the top. > Sigh. There are times when the laxness of the previous 10 years really > bugs me. This is one of them. > > Start with the template in libgcc2.c and change it to deal with header > files instead of libraries. > > Do you want to do this, or should I (or if someone else wants it, speak up). Patch appended. We still have to deal with float.h and limits.h which are generated. I personally think we should dump those files, but that's a larger issue. zw 1999-09-20 10:13 -0700 Zack Weinberg <zack@bitmover.com> * iso646.h, stdarg.h, stdbool.h, stddef.h, varargs.h: Add copyright notice and special exception to GPL. =================================================================== Index: iso646.h --- iso646.h 1998/12/16 21:19:18 1.2 +++ iso646.h 1999/09/20 17:11:58 @@ -1,5 +1,36 @@ -/* Macros for C programs written in national variants of ISO 646. */ +/* Copyright (C) 1997, 1999 Free Software Foundation, Inc. +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ + +/* + * ISO C Standard: 7.9 Alternative spellings <iso646.h> + */ + +#ifndef _ISO646_H +#define _ISO646_H + #ifndef __cplusplus #define and && #define and_eq &= @@ -12,4 +43,6 @@ #define or_eq |= #define xor ^ #define xor_eq ^= +#endif + #endif =================================================================== Index: stdarg.h --- stdarg.h 1999/09/14 23:30:44 1.10 +++ stdarg.h 1999/09/20 17:11:58 @@ -1,9 +1,33 @@ -/* stdarg.h for GNU. +/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc. - Note that the type used in va_arg is supposed to match the - actual type **after default promotions**. - Thus, va_arg (..., short) is not valid. */ +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ + +/* + * ISO C Standard: 7.15 Variable arguments <stdarg.h> + */ + #ifndef _STDARG_H #ifndef _ANSI_STDARG_H_ #ifndef __need___va_list @@ -22,6 +46,10 @@ typedef __builtin_va_list __gnuc_va_list /* Define the standard macros for the user, if this invocation was from the user program. */ #ifdef _STDARG_H + +/* Note that the type used in va_arg is supposed to match the + actual type **after default promotions**. + Thus, va_arg (..., short) is not valid. */ #define va_start(v,l) __builtin_stdarg_start(&(v),l) #define va_end __builtin_va_end =================================================================== Index: stdbool.h --- stdbool.h 1999/08/29 15:46:14 1.3 +++ stdbool.h 1999/09/20 17:11:58 @@ -1,6 +1,35 @@ -/* stdbool.h for GNU. */ -#ifndef __STDBOOL_H__ -#define __STDBOOL_H__ 1 +/* Copyright (C) 1998, 1999 Free Software Foundation, Inc. + +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ + +/* + * ISO C Standard: 7.16 Boolean type and values <stdbool.h> + */ + +#ifndef _STDBOOL_H +#define _STDBOOL_H /* The type `_Bool' must promote to `int' or `unsigned int'. The constants `true' and `false' must have the value 0 and 1 respectively. */ =================================================================== Index: stddef.h --- stddef.h 1998/12/16 21:19:25 1.4 +++ stddef.h 1999/09/20 17:11:58 @@ -1,3 +1,32 @@ +/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc. + +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ + +/* + * ISO C Standard: 7.17 Common definitions <stddef.h> + */ #if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \ && !defined(__STDDEF_H__)) \ || defined(__need_wchar_t) || defined(__need_size_t) \ =================================================================== Index: varargs.h --- varargs.h 1999/09/14 23:30:44 1.12 +++ varargs.h 1999/09/20 17:11:58 @@ -1,4 +1,28 @@ -/* Record that this is varargs.h; this turns off stdarg.h. */ +/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc. + +This file is part of GNU CC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU CC; see the file COPYING. If not, write to +the Free Software Foundation, 59 Temple Place - Suite 330, +Boston, MA 02111-1307, USA. */ + +/* As a special exception, if you include this header file into source + files compiled by GCC, this header file does not by itself cause + the resulting executable to be covered by the GNU General Public + License. This exception does not however invalidate any other + reasons why the executable file might be covered by the GNU General + Public License. */ #ifndef _VARARGS_H #define _VARARGS_H ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 9:55 ` Jeffrey A Law 1999-09-20 10:17 ` Zack Weinberg @ 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: obrien, rittle, morganw, rth, gcc, pfeifer In message < 199909201624.JAA16030@zack.bitmover.com >you write: > Jeffrey A Law wrote: > > In message < 19990915011710.B25121@relay.nuxi.com >you write: > > > There are no GCC headers in my base system. We've never needed them, > and > > > there are copyright issues anyway. > > What copyright issues? > > There is no explicit license/copyright statement at the top of > stddef.h or stdarg.h or whatever. Someone could easily have been > misled into thinking that they were GPLed and would infect programs. > > We should probably put something like the libstdc++ "special > exception" paragraph at the top. Sigh. There are times when the laxness of the previous 10 years really bugs me. This is one of them. Start with the template in libgcc2.c and change it to deal with header files instead of libraries. Do you want to do this, or should I (or if someone else wants it, speak up). jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 9:26 ` Zack Weinberg 1999-09-20 9:55 ` Jeffrey A Law @ 1999-09-30 18:02 ` Zack Weinberg 1 sibling, 0 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-30 18:02 UTC (permalink / raw) To: law; +Cc: obrien, rittle, morganw, rth, gcc, pfeifer Jeffrey A Law wrote: > In message < 19990915011710.B25121@relay.nuxi.com >you write: > > There are no GCC headers in my base system. We've never needed them, and > > there are copyright issues anyway. > What copyright issues? There is no explicit license/copyright statement at the top of stddef.h or stdarg.h or whatever. Someone could easily have been misled into thinking that they were GPLed and would infect programs. We should probably put something like the libstdc++ "special exception" paragraph at the top. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 4:34 ` Jeffrey A Law 1999-09-20 9:26 ` Zack Weinberg @ 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: Zack Weinberg, rittle, morganw, rth, gcc, pfeifer In message < 19990915011710.B25121@relay.nuxi.com >you write: > There are no GCC headers in my base system. We've never needed them, and > there are copyright issues anyway. What copyright issues? jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:17 ` David O'Brien 1999-09-15 9:23 ` Zack Weinberg 1999-09-20 4:34 ` Jeffrey A Law @ 1999-09-30 18:02 ` David O'Brien 2 siblings, 0 replies; 107+ messages in thread From: David O'Brien @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: rittle, morganw, rth, gcc, pfeifer > Because the "real" type is __gnuc_va_list. Doing it your way won't do > what you want. I hope you don't have system headers that typedef > _BSD_VA_LIST_ without reference to gcc's stdarg.h - from /usr/include/machine/ansi.h #define _BSD_VA_LIST_ char * /* va_list */ There are no GCC headers in my base system. We've never needed them, and there are copyright issues anyway. > for one thing, we probably just irrevocably broke them. That is not good. (doesn't anyone there have access to a BSD machine??) > The problem with __gnuc_va_list is primarily aesthetic. If it is only aesthetics then lets leave it alone. > Everyone has to agree on the underlying typedef name because of C++ > mangled names. Therefore I would like the underlying typedef name to > be compiler-neutral. If you want g++ compiled by someone under FreeBSD to work with the base compiler, libs etc. the type will need to be _BSD_VA_LIST_ (char *). > People do want to use glibc with compilers other than gcc. I don't care what other people do with glibc. -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 0:25 ` Zack Weinberg 1999-09-15 0:56 ` David O'Brien 1999-09-15 1:17 ` David O'Brien @ 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 0 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: rittle, morganw, rth, gcc, pfeifer "David O'Brien" wrote: > > May I suggest that stdarg.h/varargs.h be modified to #define > > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to > > limit it to FreeBSD? > > Why not do it the other way around? > > #define __gnuc_va_list _BSD_VA_LIST_ Because the "real" type is __gnuc_va_list. Doing it your way won't do what you want. I hope you don't have system headers that typedef _BSD_VA_LIST_ without reference to gcc's stdarg.h - for one thing, we probably just irrevocably broke them. > Please, please lets not require the dinking of many system headers. > Please also remember GCC is the base compiler in BSD and the number of > things that have to be changed when native'ifing the compiler the better. I believe #define _BSD_VA_LIST_ __gnuc_va_list will solve your problem without any dinking of BSD libc headers. > > (Is this needed by Net/OpenBSD too?) This is simpler and less fragile > > than adding stuff to fixinc. > > This is a 4.4BSD thing. It thus affects all of BSD. Is there any macro which is defined by all 4.4-derived systems? > > For complicated reasons related to similar interactions with glibc's > > headers, I'd personally like to see the typedef name be __va_list, and > > __gnuc_va_list a #define as well. > > Can you explain these interactions? I really doubt the BSD headers are > as intertwined. The intertwining with glibc is not as bad as you might think, and __gnuc_va_list is actually the least bad part. For real issues, try to figure out what wint_t is doing in stddef.h, or how limits.h works. The problem with __gnuc_va_list is primarily aesthetic. Everyone has to agree on the underlying typedef name because of C++ mangled names. Therefore I would like the underlying typedef name to be compiler-neutral. People do want to use glibc with compilers other than gcc. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 23:14 ` David O'Brien 1999-09-15 0:25 ` Zack Weinberg @ 1999-09-15 2:00 ` Jeffrey A Law 1999-09-15 2:25 ` David O'Brien ` (2 more replies) 1999-09-30 18:02 ` David O'Brien 2 siblings, 3 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-15 2:00 UTC (permalink / raw) To: obrien; +Cc: Zack Weinberg In message < 19990914231414.B17808@dragon.nuxi.com >you write: > > May I suggest that stdarg.h/varargs.h be modified to #define > > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to > > limit it to FreeBSD? > > Why not do it the other way around? > > #define __gnuc_va_list _BSD_VA_LIST_ > > Please, please lets not require the dinking of many system headers. > Please also remember GCC is the base compiler in BSD and the number of > things that have to be changed when native'ifing the compiler the better. That seems backwards. When doing varargs/stdargs we absolutely do not want to be using system definitions. Even if the system compiler is gcc. > > (Is this needed by Net/OpenBSD too?) This is simpler and less fragile > > than adding stuff to fixinc. > > This is a 4.4BSD thing. It thus affects all of BSD. Be careful with that statement, while they all come from the same lineage, each has hacked things up in their own special way. And they're currently treating USER_H and fixinc issues differently. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 2:00 ` Jeffrey A Law @ 1999-09-15 2:25 ` David O'Brien 1999-09-15 2:33 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien [not found] ` <37DFAD27.3E6A25E3@datadesign.com> 1999-09-30 18:02 ` Jeffrey A Law 2 siblings, 2 replies; 107+ messages in thread From: David O'Brien @ 1999-09-15 2:25 UTC (permalink / raw) To: Jeffrey A Law; +Cc: Zack Weinberg > When doing varargs/stdargs we absolutely do not want to be using system > definitions. Even if the system compiler is gcc. Can't this cause incompatibilities with libs and .o's compiled with the base compiler? -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 2:25 ` David O'Brien @ 1999-09-15 2:33 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 1 sibling, 1 reply; 107+ messages in thread From: Jeffrey A Law @ 1999-09-15 2:33 UTC (permalink / raw) To: obrien; +Cc: Zack Weinberg In message < 19990915022452.F17808@dragon.nuxi.com >you write: > > When doing varargs/stdargs we absolutely do not want to be using system > > definitions. Even if the system compiler is gcc. > > Can't this cause incompatibilities with libs and .o's compiled with the > base compiler? If the underlying structures for va_list change, yes, but then again, in that case you're hosed beyond belief anyway. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 2:33 ` Jeffrey A Law @ 1999-09-30 18:02 ` Jeffrey A Law 0 siblings, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: Zack Weinberg, rittle, morganw, rth, gcc, pfeifer In message < 19990915022452.F17808@dragon.nuxi.com >you write: > > When doing varargs/stdargs we absolutely do not want to be using system > > definitions. Even if the system compiler is gcc. > > Can't this cause incompatibilities with libs and .o's compiled with the > base compiler? If the underlying structures for va_list change, yes, but then again, in that case you're hosed beyond belief anyway. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 2:25 ` David O'Brien 1999-09-15 2:33 ` Jeffrey A Law @ 1999-09-30 18:02 ` David O'Brien 1 sibling, 0 replies; 107+ messages in thread From: David O'Brien @ 1999-09-30 18:02 UTC (permalink / raw) To: Jeffrey A Law; +Cc: Zack Weinberg, rittle, morganw, rth, gcc, pfeifer > When doing varargs/stdargs we absolutely do not want to be using system > definitions. Even if the system compiler is gcc. Can't this cause incompatibilities with libs and .o's compiled with the base compiler? -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
[parent not found: <37DFAD27.3E6A25E3@datadesign.com>]
[parent not found: <199909152042.PAA29374@latour.rsch.comm.mot.com>]
* Re: FreeBSD 4.0 [not found] ` <199909152042.PAA29374@latour.rsch.comm.mot.com> @ 1999-09-15 14:26 ` Bruce Korb 1999-09-15 17:10 ` Jeffrey A Law 1999-09-30 18:02 ` Bruce Korb 0 siblings, 2 replies; 107+ messages in thread From: Bruce Korb @ 1999-09-15 14:26 UTC (permalink / raw) To: rittle; +Cc: gcc Loren James Rittle wrote: > Hi Bruce, > > The issue is that stdio.h isn't the only system header under [Free]BSD > that uses the _BSD_VA_LIST_ define. Basically, approximately 10 other > system header files need the same treatment as stdio.h. > > In your opinion, should all those other headers be processed just like > stdio.h? Or, do you need more input on the matter? > > There is another camp that dislikes this approach since they want to > use gcc as the default compiler on the system and really want > _BSD_VA_LIST_ to appear in the /usr/include version of the headers. First off, I am strongly in the camp that says the fewer headers that get secreted off some place the better. In other words, if the standard BSD compiler is GCC, then the standard BSD headers should be compatible with it. From the perspective that the future will be compatible, the remaining question is what to do on older systems that use _BSD_VA_LIST_. The most straght forward answer is: do that which has the smallest impact while still being certain to not break other implementations. Since I do not know the exact usage of the _BSD_VA_LIST_ token, I hesitate to propose a solution. But the solution should vanish in the next few decades as the old implementations die away :-). In other words, fix the old systems with fixinc and the new ones with source changes. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 14:26 ` Bruce Korb @ 1999-09-15 17:10 ` Jeffrey A Law 1999-09-16 1:46 ` Marc Espie 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Bruce Korb 1 sibling, 2 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-15 17:10 UTC (permalink / raw) To: ddsinc09; +Cc: rittle In message < 37E00F41.AF49518@datadesign.com >you write: > First off, I am strongly in the camp that says the fewer headers > that get secreted off some place the better. In other words, > if the standard BSD compiler is GCC, then the standard BSD headers > should be compatible with it. But, unfortunately, header requirements change over time. This is precisely the problem we have had with the *BSD* systems over the years. Back in 1991 or so I put in a change which made GCC avoid installing its own internal header files for "Net-2" systems (upon which all the *BSD variants are derived. That turned out to be a huge, unbelievably stupid, thing to do. Why? Because when we needed to provide a magic symbol (I believe in stddef.h) to ensure that C++ adhered to the proper definition of NULL the *BSD systems did not get that definition. Or another example would be the need to massage math.h because it had "struct exception" in it and "exception" became a reserved word for C++. > >From the perspective that the future will be compatible, That is not an assumption we can safely make because the requirements do change over time and GCC needs to continue to work when those requirements change. > The most straght forward answer is: do that which has the smallest > impact while still being certain to not break other implementations. I certainly agree with this. However, it has to include installation of the GCC header files, now and in the future. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 17:10 ` Jeffrey A Law @ 1999-09-16 1:46 ` Marc Espie 1999-09-16 6:57 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 2 replies; 107+ messages in thread From: Marc Espie @ 1999-09-16 1:46 UTC (permalink / raw) To: law; +Cc: egcs In article < 14810.937440488@upchuck.cygnus.com > you write: > In message < 37E00F41.AF49518@datadesign.com >you write: > > First off, I am strongly in the camp that says the fewer headers > > that get secreted off some place the better. In other words, > > if the standard BSD compiler is GCC, then the standard BSD headers > > should be compatible with it. >But, unfortunately, header requirements change over time. This is precisely >the problem we have had with the *BSD* systems over the years. >Back in 1991 or so I put in a change which made GCC avoid installing its >own internal header files for "Net-2" systems (upon which all the *BSD variants >are derived. >That turned out to be a huge, unbelievably stupid, thing to do. Why? Because >when we needed to provide a magic symbol (I believe in stddef.h) to ensure >that C++ adhered to the proper definition of NULL the *BSD systems did not >get that definition. As far as OpenBSD goes, we are willing to fix our header files over time. The NULL issue is now solved, and everything will be alright in that regards for 2.6. I'm even in the process of trying to replace (cast)(value) in the include files by macros that read __static_cast(cast, value). I also would like to thoroughly annotate math functions with __attribute__((const)) when I can. I'm still a bit unclear whether a function that may fault with a SIGFPE, such as atan, is a good candidate for __attribute__((const)) or not. > > >From the perspective that the future will be compatible, >That is not an assumption we can safely make because the requirements do >change over time and GCC needs to continue to work when those requirements >change. As long as `new' requirements stay reasonably clear, this is not such a large problem... what bites is not having clear requirements, or not being up to speed yet, as occurred for the __null issue. In fact, this is simpler work than fixincludes, since I am in a position to fix one set of headers without having to care about the rest. We can provide header archives to install with the compiler, if updates are needed. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 1:46 ` Marc Espie @ 1999-09-16 6:57 ` Jeffrey A Law 1999-09-16 7:41 ` Marc Espie 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1 sibling, 2 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-16 6:57 UTC (permalink / raw) To: Marc Espie; +Cc: egcs In message < 199909160846.KAA29697@quatramaran.ens.fr >you write: > As far as OpenBSD goes, we are willing to fix our header files over time. > The NULL issue is now solved, and everything will be alright in that > regards for 2.6. That doesn't matter. GCC still needs to work on those systems where you have not updated your header files. Or if we find another need to update a header file it is not acceptable to have to wait for another OpenBSD release to fix the header files. Quite simply, the USER_H overrides are wrong and must go. Period. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 6:57 ` Jeffrey A Law @ 1999-09-16 7:41 ` Marc Espie 1999-09-16 7:55 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 2 replies; 107+ messages in thread From: Marc Espie @ 1999-09-16 7:41 UTC (permalink / raw) To: law; +Cc: egcs In article < 16930.937487529@upchuck.cygnus.com > you write: > In message < 199909160846.KAA29697@quatramaran.ens.fr >you write: > > As far as OpenBSD goes, we are willing to fix our header files over time. > > The NULL issue is now solved, and everything will be alright in that > > regards for 2.6. >That doesn't matter. GCC still needs to work on those systems where you have >not updated your header files. Or if we find another need to update a header >file it is not acceptable to have to wait for another OpenBSD release to fix >the header files. >Quite simply, the USER_H overrides are wrong and must go. Period. No, there are two issues at work. I concur that, if the end user want to fiddle with a newer gcc snapshot, USER_H is in the way. HOWEVER, from the OpenBSD release point of view, we want to go on fixing include files, and provide our own. I believe that both goals are not contradictory. Specifically, when installed as the system compiler, gcc WILL use the system includes, and it should work with them. If fixincludes has to tweak those headers, OR if gcc should head its own headers, well... then it's a bug in our system headers, and we want to fix that... worse than that: it's a deadly bug; there are parts of the system, such as the kernel, which are built -nostdinc, and which desperately need the system headers to be correct. If a user wants to install a more recent gcc to fiddle with it (or a gcc on an ancient system that, for some strange reason, they don't want to upgrade), no problem with having it install its more modern version of include files and running fixincludes and so on... If you prefer, there are two software packages to maintain here: gcc and OpenBSD. Your goal is to ensure gcc's headers and fixincludes work. My goal is to ensure OpenBSD system headers are fine. Allow me to defend my own turf... ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 7:41 ` Marc Espie @ 1999-09-16 7:55 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1 sibling, 1 reply; 107+ messages in thread From: Jeffrey A Law @ 1999-09-16 7:55 UTC (permalink / raw) To: Marc Espie; +Cc: egcs In message < 199909161441.QAA03626@quatramaran.ens.fr >you write: > >Quite simply, the USER_H overrides are wrong and must go. Period. > > No, there are two issues at work. > > I concur that, if the end user want to fiddle with a newer gcc snapshot, > USER_H is in the way. > > HOWEVER, from the OpenBSD release point of view, we want to go on fixing > include files, and provide our own. > > I believe that both goals are not contradictory. Specifically, when > installed as the system compiler, gcc WILL use the system includes, and > it should work with them. If fixincludes has to tweak those headers, > OR if gcc should head its own headers, well... then it's a bug in our > system headers, and we want to fix that... worse than that: it's a deadly > bug; there are parts of the system, such as the kernel, which are built > -nostdinc, and which desperately need the system headers to be correct. No. Absolutely not. Overriding USER_H is wrong. Period. No ifs, ands or buts. It will go away. I strongly recommend you stop using it. Like so many of the other braindamaged things you're doing because you think things need to work "specially" because gcc can be the system compiler are dumb and can be easily avoided. By not doing all those dumb and special things I think you'll find that over time that things will "just work" instead of having to continually tweak it. I'll repeat, overriding USER_H is absolutely and completely wrong in all situations. Period. This is not subject to debate. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 7:55 ` Jeffrey A Law @ 1999-09-30 18:02 ` Jeffrey A Law 0 siblings, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: Marc Espie; +Cc: egcs In message < 199909161441.QAA03626@quatramaran.ens.fr >you write: > >Quite simply, the USER_H overrides are wrong and must go. Period. > > No, there are two issues at work. > > I concur that, if the end user want to fiddle with a newer gcc snapshot, > USER_H is in the way. > > HOWEVER, from the OpenBSD release point of view, we want to go on fixing > include files, and provide our own. > > I believe that both goals are not contradictory. Specifically, when > installed as the system compiler, gcc WILL use the system includes, and > it should work with them. If fixincludes has to tweak those headers, > OR if gcc should head its own headers, well... then it's a bug in our > system headers, and we want to fix that... worse than that: it's a deadly > bug; there are parts of the system, such as the kernel, which are built > -nostdinc, and which desperately need the system headers to be correct. No. Absolutely not. Overriding USER_H is wrong. Period. No ifs, ands or buts. It will go away. I strongly recommend you stop using it. Like so many of the other braindamaged things you're doing because you think things need to work "specially" because gcc can be the system compiler are dumb and can be easily avoided. By not doing all those dumb and special things I think you'll find that over time that things will "just work" instead of having to continually tweak it. I'll repeat, overriding USER_H is absolutely and completely wrong in all situations. Period. This is not subject to debate. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 7:41 ` Marc Espie 1999-09-16 7:55 ` Jeffrey A Law @ 1999-09-30 18:02 ` Marc Espie 1 sibling, 0 replies; 107+ messages in thread From: Marc Espie @ 1999-09-30 18:02 UTC (permalink / raw) To: law; +Cc: egcs In article < 16930.937487529@upchuck.cygnus.com > you write: > In message < 199909160846.KAA29697@quatramaran.ens.fr >you write: > > As far as OpenBSD goes, we are willing to fix our header files over time. > > The NULL issue is now solved, and everything will be alright in that > > regards for 2.6. >That doesn't matter. GCC still needs to work on those systems where you have >not updated your header files. Or if we find another need to update a header >file it is not acceptable to have to wait for another OpenBSD release to fix >the header files. >Quite simply, the USER_H overrides are wrong and must go. Period. No, there are two issues at work. I concur that, if the end user want to fiddle with a newer gcc snapshot, USER_H is in the way. HOWEVER, from the OpenBSD release point of view, we want to go on fixing include files, and provide our own. I believe that both goals are not contradictory. Specifically, when installed as the system compiler, gcc WILL use the system includes, and it should work with them. If fixincludes has to tweak those headers, OR if gcc should head its own headers, well... then it's a bug in our system headers, and we want to fix that... worse than that: it's a deadly bug; there are parts of the system, such as the kernel, which are built -nostdinc, and which desperately need the system headers to be correct. If a user wants to install a more recent gcc to fiddle with it (or a gcc on an ancient system that, for some strange reason, they don't want to upgrade), no problem with having it install its more modern version of include files and running fixincludes and so on... If you prefer, there are two software packages to maintain here: gcc and OpenBSD. Your goal is to ensure gcc's headers and fixincludes work. My goal is to ensure OpenBSD system headers are fine. Allow me to defend my own turf... ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 6:57 ` Jeffrey A Law 1999-09-16 7:41 ` Marc Espie @ 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: Marc Espie; +Cc: egcs In message < 199909160846.KAA29697@quatramaran.ens.fr >you write: > As far as OpenBSD goes, we are willing to fix our header files over time. > The NULL issue is now solved, and everything will be alright in that > regards for 2.6. That doesn't matter. GCC still needs to work on those systems where you have not updated your header files. Or if we find another need to update a header file it is not acceptable to have to wait for another OpenBSD release to fix the header files. Quite simply, the USER_H overrides are wrong and must go. Period. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 1:46 ` Marc Espie 1999-09-16 6:57 ` Jeffrey A Law @ 1999-09-30 18:02 ` Marc Espie 1 sibling, 0 replies; 107+ messages in thread From: Marc Espie @ 1999-09-30 18:02 UTC (permalink / raw) To: law; +Cc: egcs In article < 14810.937440488@upchuck.cygnus.com > you write: > In message < 37E00F41.AF49518@datadesign.com >you write: > > First off, I am strongly in the camp that says the fewer headers > > that get secreted off some place the better. In other words, > > if the standard BSD compiler is GCC, then the standard BSD headers > > should be compatible with it. >But, unfortunately, header requirements change over time. This is precisely >the problem we have had with the *BSD* systems over the years. >Back in 1991 or so I put in a change which made GCC avoid installing its >own internal header files for "Net-2" systems (upon which all the *BSD variants >are derived. >That turned out to be a huge, unbelievably stupid, thing to do. Why? Because >when we needed to provide a magic symbol (I believe in stddef.h) to ensure >that C++ adhered to the proper definition of NULL the *BSD systems did not >get that definition. As far as OpenBSD goes, we are willing to fix our header files over time. The NULL issue is now solved, and everything will be alright in that regards for 2.6. I'm even in the process of trying to replace (cast)(value) in the include files by macros that read __static_cast(cast, value). I also would like to thoroughly annotate math functions with __attribute__((const)) when I can. I'm still a bit unclear whether a function that may fault with a SIGFPE, such as atan, is a good candidate for __attribute__((const)) or not. > > >From the perspective that the future will be compatible, >That is not an assumption we can safely make because the requirements do >change over time and GCC needs to continue to work when those requirements >change. As long as `new' requirements stay reasonably clear, this is not such a large problem... what bites is not having clear requirements, or not being up to speed yet, as occurred for the __null issue. In fact, this is simpler work than fixincludes, since I am in a position to fix one set of headers without having to care about the rest. We can provide header archives to install with the compiler, if updates are needed. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 17:10 ` Jeffrey A Law 1999-09-16 1:46 ` Marc Espie @ 1999-09-30 18:02 ` Jeffrey A Law 1 sibling, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: ddsinc09; +Cc: rittle, gcc In message < 37E00F41.AF49518@datadesign.com >you write: > First off, I am strongly in the camp that says the fewer headers > that get secreted off some place the better. In other words, > if the standard BSD compiler is GCC, then the standard BSD headers > should be compatible with it. But, unfortunately, header requirements change over time. This is precisely the problem we have had with the *BSD* systems over the years. Back in 1991 or so I put in a change which made GCC avoid installing its own internal header files for "Net-2" systems (upon which all the *BSD variants are derived. That turned out to be a huge, unbelievably stupid, thing to do. Why? Because when we needed to provide a magic symbol (I believe in stddef.h) to ensure that C++ adhered to the proper definition of NULL the *BSD systems did not get that definition. Or another example would be the need to massage math.h because it had "struct exception" in it and "exception" became a reserved word for C++. > >From the perspective that the future will be compatible, That is not an assumption we can safely make because the requirements do change over time and GCC needs to continue to work when those requirements change. > The most straght forward answer is: do that which has the smallest > impact while still being certain to not break other implementations. I certainly agree with this. However, it has to include installation of the GCC header files, now and in the future. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 14:26 ` Bruce Korb 1999-09-15 17:10 ` Jeffrey A Law @ 1999-09-30 18:02 ` Bruce Korb 1 sibling, 0 replies; 107+ messages in thread From: Bruce Korb @ 1999-09-30 18:02 UTC (permalink / raw) To: rittle; +Cc: gcc Loren James Rittle wrote: > Hi Bruce, > > The issue is that stdio.h isn't the only system header under [Free]BSD > that uses the _BSD_VA_LIST_ define. Basically, approximately 10 other > system header files need the same treatment as stdio.h. > > In your opinion, should all those other headers be processed just like > stdio.h? Or, do you need more input on the matter? > > There is another camp that dislikes this approach since they want to > use gcc as the default compiler on the system and really want > _BSD_VA_LIST_ to appear in the /usr/include version of the headers. First off, I am strongly in the camp that says the fewer headers that get secreted off some place the better. In other words, if the standard BSD compiler is GCC, then the standard BSD headers should be compatible with it. From the perspective that the future will be compatible, the remaining question is what to do on older systems that use _BSD_VA_LIST_. The most straght forward answer is: do that which has the smallest impact while still being certain to not break other implementations. Since I do not know the exact usage of the _BSD_VA_LIST_ token, I hesitate to propose a solution. But the solution should vanish in the next few decades as the old implementations die away :-). In other words, fix the old systems with fixinc and the new ones with source changes. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 2:00 ` Jeffrey A Law 1999-09-15 2:25 ` David O'Brien [not found] ` <37DFAD27.3E6A25E3@datadesign.com> @ 1999-09-30 18:02 ` Jeffrey A Law 2 siblings, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: obrien; +Cc: Zack Weinberg, rittle, morganw, rth, gcc, pfeifer In message < 19990914231414.B17808@dragon.nuxi.com >you write: > > May I suggest that stdarg.h/varargs.h be modified to #define > > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to > > limit it to FreeBSD? > > Why not do it the other way around? > > #define __gnuc_va_list _BSD_VA_LIST_ > > Please, please lets not require the dinking of many system headers. > Please also remember GCC is the base compiler in BSD and the number of > things that have to be changed when native'ifing the compiler the better. That seems backwards. When doing varargs/stdargs we absolutely do not want to be using system definitions. Even if the system compiler is gcc. > > (Is this needed by Net/OpenBSD too?) This is simpler and less fragile > > than adding stuff to fixinc. > > This is a 4.4BSD thing. It thus affects all of BSD. Be careful with that statement, while they all come from the same lineage, each has hacked things up in their own special way. And they're currently treating USER_H and fixinc issues differently. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 23:14 ` David O'Brien 1999-09-15 0:25 ` Zack Weinberg 1999-09-15 2:00 ` Jeffrey A Law @ 1999-09-30 18:02 ` David O'Brien 2 siblings, 0 replies; 107+ messages in thread From: David O'Brien @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: rittle, morganw, rth, gcc, obrien, pfeifer > May I suggest that stdarg.h/varargs.h be modified to #define > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to > limit it to FreeBSD? Why not do it the other way around? #define __gnuc_va_list _BSD_VA_LIST_ Please, please lets not require the dinking of many system headers. Please also remember GCC is the base compiler in BSD and the number of things that have to be changed when native'ifing the compiler the better. > (Is this needed by Net/OpenBSD too?) This is simpler and less fragile > than adding stuff to fixinc. This is a 4.4BSD thing. It thus affects all of BSD. > For complicated reasons related to similar interactions with glibc's > headers, I'd personally like to see the typedef name be __va_list, and > __gnuc_va_list a #define as well. Can you explain these interactions? I really doubt the BSD headers are as intertwined. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 23:00 ` Zack Weinberg 1999-09-14 23:14 ` David O'Brien @ 1999-09-15 1:59 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 1 reply; 107+ messages in thread From: Jeffrey A Law @ 1999-09-15 1:59 UTC (permalink / raw) To: Zack Weinberg; +Cc: rittle In message < 199909150601.XAA22053@zack.bitmover.com >you write: > May I suggest that stdarg.h/varargs.h be modified to #define > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to > limit it to FreeBSD? (Is this needed by Net/OpenBSD too?) This is > simpler and less fragile than adding stuff to fixinc. NetBSD and OpenBSD will need the same treatment when we kill the amazingly braindamaged USER_H override in their makefile fragments. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 1:59 ` Jeffrey A Law @ 1999-09-30 18:02 ` Jeffrey A Law 0 siblings, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: Zack Weinberg; +Cc: rittle, morganw, rth, gcc, obrien, pfeifer In message < 199909150601.XAA22053@zack.bitmover.com >you write: > May I suggest that stdarg.h/varargs.h be modified to #define > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to > limit it to FreeBSD? (Is this needed by Net/OpenBSD too?) This is > simpler and less fragile than adding stuff to fixinc. NetBSD and OpenBSD will need the same treatment when we kill the amazingly braindamaged USER_H override in their makefile fragments. jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 23:00 ` Zack Weinberg 1999-09-14 23:14 ` David O'Brien 1999-09-15 1:59 ` Jeffrey A Law @ 1999-09-30 18:02 ` Zack Weinberg 2 siblings, 0 replies; 107+ messages in thread From: Zack Weinberg @ 1999-09-30 18:02 UTC (permalink / raw) To: rittle; +Cc: morganw, rth, gcc, obrien, pfeifer Loren James Rittle wrote: > > Unfortunately (although extremely minor), that means that until I get > around to investigating the root issue in fixinc, any C++ code that > relies on system headers which use _BSD_VA_LIST_ instead of va_list > (not including stdio.h which is now correctly fixed) will fail with > errors of this form: > > cannot convert `void *' to `char *' for argument `X' to `foo(...)' > > Richard, is it your position that all system headers must be fixed to > only reference __gnuc_va_list instead of va_list and/or > system-specific macros such as _BSD_VA_LIST_ (as was historically used > by BSD systems)? If so, then fixinc's rule to mung _BSD_VA_LIST_ into > __gnuc_va_list must be expanded to operate on 10-15 other standard BSD > system headers... May I suggest that stdarg.h/varargs.h be modified to #define _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to limit it to FreeBSD? (Is this needed by Net/OpenBSD too?) This is simpler and less fragile than adding stuff to fixinc. For complicated reasons related to similar interactions with glibc's headers, I'd personally like to see the typedef name be __va_list, and __gnuc_va_list a #define as well. zw ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 22:34 ` Loren James Rittle 1999-09-14 23:00 ` Zack Weinberg @ 1999-09-15 7:42 ` Wes Morgan 1999-09-30 18:02 ` Wes Morgan 1999-09-30 18:02 ` Loren James Rittle 2 siblings, 1 reply; 107+ messages in thread From: Wes Morgan @ 1999-09-15 7:42 UTC (permalink / raw) To: rittle; +Cc: rth On Wed, 15 Sep 1999, Loren James Rittle wrote: > Cool! If you have upgraded past gcc_ss_19990913 and picked up > Richard's latest changes, then I can now confirm (since I just > finished a bootstrap on the mainline with his changes) that the > gcc/ginclude/stdarg.h and gcc/ginclude/varargs.h patches are no longer > needed (since he removed the code that those patches affected ;-)! Same thing here. Using the CVS stdarg and varargs, applying the patch only to t-freebsd, I get a successfull build of the C and C++ compilers (I don't bother with any of the others). I don't have dejagnu installed for fbsd though, so I don't know the results of a make check. WM -- The difference between genius and stupidity is that genius has its limits. Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-15 7:42 ` Wes Morgan @ 1999-09-30 18:02 ` Wes Morgan 0 siblings, 0 replies; 107+ messages in thread From: Wes Morgan @ 1999-09-30 18:02 UTC (permalink / raw) To: rittle; +Cc: rth, gcc, obrien, pfeifer On Wed, 15 Sep 1999, Loren James Rittle wrote: > Cool! If you have upgraded past gcc_ss_19990913 and picked up > Richard's latest changes, then I can now confirm (since I just > finished a bootstrap on the mainline with his changes) that the > gcc/ginclude/stdarg.h and gcc/ginclude/varargs.h patches are no longer > needed (since he removed the code that those patches affected ;-)! Same thing here. Using the CVS stdarg and varargs, applying the patch only to t-freebsd, I get a successfull build of the C and C++ compilers (I don't bother with any of the others). I don't have dejagnu installed for fbsd though, so I don't know the results of a make check. WM -- The difference between genius and stupidity is that genius has its limits. Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-14 22:34 ` Loren James Rittle 1999-09-14 23:00 ` Zack Weinberg 1999-09-15 7:42 ` Wes Morgan @ 1999-09-30 18:02 ` Loren James Rittle 2 siblings, 0 replies; 107+ messages in thread From: Loren James Rittle @ 1999-09-30 18:02 UTC (permalink / raw) To: morganw; +Cc: rth, gcc, obrien, pfeifer Wes Morgan wrote: > Trying to build the latest CVS snapshot under freebsd 4.0 fails with these > errors: ... > include/stdio.h:245: parse error before `__gnuc_va_list' ... > There are a few mentions of fixing _BSD_VA_LIST_ to __gnuc_va_list in some > of the changelogs, but I haven't seen anything conclusive... Is this a > known problem, or is my CVS tree out of sync somehow? Or maybe I need to > set some different CFLAGS? I have built gcc_ss_19990913 on FreeBSD 3.2-RELEASE with the patches in http://egcs.cygnus.com/ml/gcc-patches/1999-08/msg00728.html (they have been *REQUIRED* on FreeBSD for some time). The issue is that ports may no longer override USER_T in order to keep fixinc from running. Richard Henderson wrote: > I just checked in a much simplified version of stdarg.h. > Would you send me a preprocessed copy and we can figure > out what went wrong. Cool! If you have upgraded past gcc_ss_19990913 and picked up Richard's latest changes, then I can now confirm (since I just finished a bootstrap on the mainline with his changes) that the gcc/ginclude/stdarg.h and gcc/ginclude/varargs.h patches are no longer needed (since he removed the code that those patches affected ;-)! Unfortunately (although extremely minor), that means that until I get around to investigating the root issue in fixinc, any C++ code that relies on system headers which use _BSD_VA_LIST_ instead of va_list (not including stdio.h which is now correctly fixed) will fail with errors of this form: cannot convert `void *' to `char *' for argument `X' to `foo(...)' Richard, is it your position that all system headers must be fixed to only reference __gnuc_va_list instead of va_list and/or system-specific macros such as _BSD_VA_LIST_ (as was historically used by BSD systems)? If so, then fixinc's rule to mung _BSD_VA_LIST_ into __gnuc_va_list must be expanded to operate on 10-15 other standard BSD system headers... Wes, if you could tell me if the referenced patches work for you under FreeBSD 4.0, that could be helpful. Regards, Loren ^ permalink raw reply [flat|nested] 107+ messages in thread
* FreeBSD 4.0 1999-09-14 19:32 FreeBSD 4.0 Wes Morgan 1999-09-14 20:08 ` Richard Henderson 1999-09-14 22:34 ` Loren James Rittle @ 1999-09-30 18:02 ` Wes Morgan 2 siblings, 0 replies; 107+ messages in thread From: Wes Morgan @ 1999-09-30 18:02 UTC (permalink / raw) To: gcc Trying to build the latest CVS snapshot under freebsd 4.0 fails with these errors: In file included from ../../egcs/gcc/libgcc2.c:1408: include/stdio.h:245: parse error before `__gnuc_va_list' include/stdio.h:246: parse error before `__gnuc_va_list' include/stdio.h:247: parse error before `__gnuc_va_list' include/stdio.h:311: parse error before `__gnuc_va_list' include/stdio.h:313: parse error before `__gnuc_va_list' include/stdio.h:315: parse error before `__gnuc_va_list' include/stdio.h:316: parse error before `__gnuc_va_list' include/stdio.h:346: parse error before `__gnuc_va_list' *** Error code 1 There are a few mentions of fixing _BSD_VA_LIST_ to __gnuc_va_list in some of the changelogs, but I haven't seen anything conclusive... Is this a known problem, or is my CVS tree out of sync somehow? Or maybe I need to set some different CFLAGS? WM -- The difference between genius and stupidity is that genius has its limits. Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 @ 1999-09-16 12:42 Mike Stump 1999-09-30 18:02 ` Mike Stump 0 siblings, 1 reply; 107+ messages in thread From: Mike Stump @ 1999-09-16 12:42 UTC (permalink / raw) To: espie; +Cc: egcs > Date: Thu, 16 Sep 1999 10:46:15 +0200 > From: Marc Espie <espie@quatramaran.ens.fr> > As far as OpenBSD goes, we are willing to fix our header files over time. I am sorry, but you can only do this for half of the cases. The other half imply time travel. Or put another way, fixing an old OS to conform to the wants of a new compiler, is hard. > We can provide header archives to install with the compiler, if updates > are needed. Yes, this is closer, but bear in mind that gcc doesn't _want_ to tote around every header for every OS. Instead it totes around fixincludes that can `generate on the fly' every header for every OS. And we are now right back where we started. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 12:42 Mike Stump @ 1999-09-30 18:02 ` Mike Stump 0 siblings, 0 replies; 107+ messages in thread From: Mike Stump @ 1999-09-30 18:02 UTC (permalink / raw) To: espie; +Cc: egcs > Date: Thu, 16 Sep 1999 10:46:15 +0200 > From: Marc Espie <espie@quatramaran.ens.fr> > As far as OpenBSD goes, we are willing to fix our header files over time. I am sorry, but you can only do this for half of the cases. The other half imply time travel. Or put another way, fixing an old OS to conform to the wants of a new compiler, is hard. > We can provide header archives to install with the compiler, if updates > are needed. Yes, this is closer, but bear in mind that gcc doesn't _want_ to tote around every header for every OS. Instead it totes around fixincludes that can `generate on the fly' every header for every OS. And we are now right back where we started. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 @ 1999-09-16 13:13 Mike Stump 1999-09-16 13:36 ` Marc Espie 1999-09-30 18:02 ` Mike Stump 0 siblings, 2 replies; 107+ messages in thread From: Mike Stump @ 1999-09-16 13:13 UTC (permalink / raw) To: espie; +Cc: egcs We have seen this same issue a couple of times. HJ wanted to put --prefix=/usr in the compiler for linux systems, we told him to take a leap. It is wrong, plain wrong. Only two people in the world should do that, the end user that wants to clobber his system, or that distribution manager for /usr. You are in the exact same case. You want to put things that are only relevant to your one build, but screw all the other folks in the world. gcc doesn't cater to people like you. It caters to all the other folks that want to install a new compiler in a non-conflicting way on their system. Once you readjust your philosophy around to match the gcc philosophy, you will see why what law says is true. > Date: Thu, 16 Sep 1999 16:41:15 +0200 > From: Marc Espie <espie@quatramaran.ens.fr> > I concur that, if the end user want to fiddle with a newer gcc snapshot, > USER_H is in the way. See, this is wrong. Use the phrase, if the end user wants to fiddle with a newer gcc snapshot, everything will always just work. If the distribution packager wants to build up a distribution, they will have to fiddle with USER_H... It would be nice if the internal documentation covered this some... It would be nice if --enable-distributorbuild or somesuch could make your life easier. Then we serve all folks (good in this case I think). Then HJ could put the defaulting of prefix to /usr back in. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 13:13 Mike Stump @ 1999-09-16 13:36 ` Marc Espie 1999-09-16 13:54 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1999-09-30 18:02 ` Mike Stump 1 sibling, 2 replies; 107+ messages in thread From: Marc Espie @ 1999-09-16 13:36 UTC (permalink / raw) To: mrs; +Cc: egcs In article < 199909162013.NAA10276@kankakee.wrs.com > you write: >You are in the exact same case. You want to put things that are only >relevant to your one build, but screw all the other folks in the world. I don't want to screw anybody else. I want to make sure stuff works, possibly both ways. >gcc doesn't cater to people like you. It caters to all the other >folks that want to install a new compiler in a non-conflicting way on >their system. > >Once you readjust your philosophy around to match the gcc philosophy, >you will see why what law says is true. > > >> Date: Thu, 16 Sep 1999 16:41:15 +0200 >> From: Marc Espie <espie@quatramaran.ens.fr> > >> I concur that, if the end user want to fiddle with a newer gcc snapshot, >> USER_H is in the way. > >See, this is wrong. Use the phrase, if the end user wants to fiddle >with a newer gcc snapshot, everything will always just work. If the >distribution packager wants to build up a distribution, they will have >to fiddle with USER_H... Sigh. I wonder if I speak martian of something sometimes... See, this is exactly what I mean. I do understand that the end user may want to install a newer compiler on an older OpenBSD. I have absolutely no problem with this. *of course* he shouldn't get fucked by whatever we want to do with the compiler. In fact, one point of my getting involved with gcc was to make sure what we had in tree matches *precisely* the current development tree, apart from a few, well-documented patches *and* making the patches available, so that Joe User gets a choice. What I mean is that we want to keep upgrading our system headers. We want them to work, we want the current system to match what gcc needs. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 13:36 ` Marc Espie @ 1999-09-16 13:54 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1 sibling, 1 reply; 107+ messages in thread From: Jeffrey A Law @ 1999-09-16 13:54 UTC (permalink / raw) To: Marc Espie; +Cc: mrs In message < 199909162035.WAA19219@quatramaran.ens.fr >you write: > Sigh. I wonder if I speak martian of something sometimes... > See, this is exactly what I mean. > I do understand that the end user may want to install a newer compiler > on an older OpenBSD. I have absolutely no problem with this. > *of course* he shouldn't get fucked by whatever we want to do with the > compiler. You and MRS are both wrong in this case. You still do not want to override USER_H, even if you "own" /usr as the distribution maintainer. And you'll find that if you do things the right way from the start that you won't need to override USER_H, even when building your distributions. > What I mean is that we want to keep upgrading our system headers. > We want them to work, we want the current system to match what gcc > needs. And that's fine. I did it myself in the pre-net2 days for Berkeley. To find out what's getting mashed you install the compiler, then go look at what's in its include directory. Manually filter out the small number of files it's going to always install (which you absolutely should not override). jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 13:54 ` Jeffrey A Law @ 1999-09-30 18:02 ` Jeffrey A Law 0 siblings, 0 replies; 107+ messages in thread From: Jeffrey A Law @ 1999-09-30 18:02 UTC (permalink / raw) To: Marc Espie; +Cc: mrs, egcs In message < 199909162035.WAA19219@quatramaran.ens.fr >you write: > Sigh. I wonder if I speak martian of something sometimes... > See, this is exactly what I mean. > I do understand that the end user may want to install a newer compiler > on an older OpenBSD. I have absolutely no problem with this. > *of course* he shouldn't get fucked by whatever we want to do with the > compiler. You and MRS are both wrong in this case. You still do not want to override USER_H, even if you "own" /usr as the distribution maintainer. And you'll find that if you do things the right way from the start that you won't need to override USER_H, even when building your distributions. > What I mean is that we want to keep upgrading our system headers. > We want them to work, we want the current system to match what gcc > needs. And that's fine. I did it myself in the pre-net2 days for Berkeley. To find out what's getting mashed you install the compiler, then go look at what's in its include directory. Manually filter out the small number of files it's going to always install (which you absolutely should not override). jeff ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 13:36 ` Marc Espie 1999-09-16 13:54 ` Jeffrey A Law @ 1999-09-30 18:02 ` Marc Espie 1 sibling, 0 replies; 107+ messages in thread From: Marc Espie @ 1999-09-30 18:02 UTC (permalink / raw) To: mrs; +Cc: egcs In article < 199909162013.NAA10276@kankakee.wrs.com > you write: >You are in the exact same case. You want to put things that are only >relevant to your one build, but screw all the other folks in the world. I don't want to screw anybody else. I want to make sure stuff works, possibly both ways. >gcc doesn't cater to people like you. It caters to all the other >folks that want to install a new compiler in a non-conflicting way on >their system. > >Once you readjust your philosophy around to match the gcc philosophy, >you will see why what law says is true. > > >> Date: Thu, 16 Sep 1999 16:41:15 +0200 >> From: Marc Espie <espie@quatramaran.ens.fr> > >> I concur that, if the end user want to fiddle with a newer gcc snapshot, >> USER_H is in the way. > >See, this is wrong. Use the phrase, if the end user wants to fiddle >with a newer gcc snapshot, everything will always just work. If the >distribution packager wants to build up a distribution, they will have >to fiddle with USER_H... Sigh. I wonder if I speak martian of something sometimes... See, this is exactly what I mean. I do understand that the end user may want to install a newer compiler on an older OpenBSD. I have absolutely no problem with this. *of course* he shouldn't get fucked by whatever we want to do with the compiler. In fact, one point of my getting involved with gcc was to make sure what we had in tree matches *precisely* the current development tree, apart from a few, well-documented patches *and* making the patches available, so that Joe User gets a choice. What I mean is that we want to keep upgrading our system headers. We want them to work, we want the current system to match what gcc needs. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-16 13:13 Mike Stump 1999-09-16 13:36 ` Marc Espie @ 1999-09-30 18:02 ` Mike Stump 1 sibling, 0 replies; 107+ messages in thread From: Mike Stump @ 1999-09-30 18:02 UTC (permalink / raw) To: espie, law; +Cc: egcs We have seen this same issue a couple of times. HJ wanted to put --prefix=/usr in the compiler for linux systems, we told him to take a leap. It is wrong, plain wrong. Only two people in the world should do that, the end user that wants to clobber his system, or that distribution manager for /usr. You are in the exact same case. You want to put things that are only relevant to your one build, but screw all the other folks in the world. gcc doesn't cater to people like you. It caters to all the other folks that want to install a new compiler in a non-conflicting way on their system. Once you readjust your philosophy around to match the gcc philosophy, you will see why what law says is true. > Date: Thu, 16 Sep 1999 16:41:15 +0200 > From: Marc Espie <espie@quatramaran.ens.fr> > I concur that, if the end user want to fiddle with a newer gcc snapshot, > USER_H is in the way. See, this is wrong. Use the phrase, if the end user wants to fiddle with a newer gcc snapshot, everything will always just work. If the distribution packager wants to build up a distribution, they will have to fiddle with USER_H... It would be nice if the internal documentation covered this some... It would be nice if --enable-distributorbuild or somesuch could make your life easier. Then we serve all folks (good in this case I think). Then HJ could put the defaulting of prefix to /usr back in. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 @ 1999-09-20 13:43 Mike Stump 1999-09-30 18:02 ` Mike Stump 0 siblings, 1 reply; 107+ messages in thread From: Mike Stump @ 1999-09-20 13:43 UTC (permalink / raw) To: richard.earnshaw, zack; +Cc: gcc-patches, gcc, law > Date: Mon, 20 Sep 1999 18:33:58 +0100 > From: Richard Earnshaw <rearnsha@arm.com> > But what if I want to pass my code through lint? There is no restriction against using lint. What did you want to do? The only think that _might_ at all be contentious is distributing lint libraries derived from those headers. I think our intent is to allow this on the grounds that it isn't copyrightable. It would be nice if there was wording somewhere that somehow gace permission. Other tools I think should be included (TAGS files, source code search databases) as well as lint. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: FreeBSD 4.0 1999-09-20 13:43 Mike Stump @ 1999-09-30 18:02 ` Mike Stump 0 siblings, 0 replies; 107+ messages in thread From: Mike Stump @ 1999-09-30 18:02 UTC (permalink / raw) To: richard.earnshaw, zack; +Cc: gcc-patches, gcc, law > Date: Mon, 20 Sep 1999 18:33:58 +0100 > From: Richard Earnshaw <rearnsha@arm.com> > But what if I want to pass my code through lint? There is no restriction against using lint. What did you want to do? The only think that _might_ at all be contentious is distributing lint libraries derived from those headers. I think our intent is to allow this on the grounds that it isn't copyrightable. It would be nice if there was wording somewhere that somehow gace permission. Other tools I think should be included (TAGS files, source code search databases) as well as lint. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Conerned about lack of detail in ChangeLog/commit messges @ 2000-06-08 12:42 David O'Brien 2000-06-08 15:18 ` Martin v. Loewis 2000-06-09 8:30 ` David Edelsohn 0 siblings, 2 replies; 107+ messages in thread From: David O'Brien @ 2000-06-08 12:42 UTC (permalink / raw) To: gcc Rev 1.26 of gengenrtl.c changed the gen* utils from writing to a file to writing to stdout. I noticed this when upgrading the FreeBSD stock compiler from 2.95.2 to 2.96 and all of a sudden my bmake Makefile broke. The ChangeLog entry for this change is: revision 1.26 date: 1999/09/07 05:47:55; author: law; state: Exp; lines: +142 -130 Merge in gcc2-ss-010999 This lack of detail was very annoying as I spent a lot more time than needed to verify that the differences I noticed in gen* were intentional. The diff from 1.25 to 1.26 is large enough to explain the change. Looking at ``cvs log gengenrtl.c'' I was unable to find any details on the "gcc2-ss-010999" branch. -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Conerned about lack of detail in ChangeLog/commit messges 2000-06-08 12:42 Conerned about lack of detail in ChangeLog/commit messges David O'Brien @ 2000-06-08 15:18 ` Martin v. Loewis 2000-06-09 8:30 ` David Edelsohn 1 sibling, 0 replies; 107+ messages in thread From: Martin v. Loewis @ 2000-06-08 15:18 UTC (permalink / raw) To: obrien; +Cc: gcc > The ChangeLog entry for this change is: > > revision 1.26 > date: 1999/09/07 05:47:55; author: law; state: Exp; lines: +142 -130 > Merge in gcc2-ss-010999 > > This lack of detail was very annoying as I spent a lot more time than > needed to verify that the differences I noticed in gen* were intentional. > The diff from 1.25 to 1.26 is large enough to explain the change. > Looking at ``cvs log gengenrtl.c'' I was unable to find any details on > the "gcc2-ss-010999" branch. Isn't the log message self-explanatory, at least to informed gcc contributors? That is a merge from gcc2, which used to a project different from the one that provided the current CVS archives. One of the major reasons for starting the egcs project was that it was so extremely difficult to locate the gcc2 source code - something which you are suffering from right now. The problem has been corrected today, but can't be corrected retroactively (sp?). Regards, Martin ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Conerned about lack of detail in ChangeLog/commit messges 2000-06-08 12:42 Conerned about lack of detail in ChangeLog/commit messges David O'Brien 2000-06-08 15:18 ` Martin v. Loewis @ 2000-06-09 8:30 ` David Edelsohn 2000-06-09 8:51 ` David O'Brien 1 sibling, 1 reply; 107+ messages in thread From: David Edelsohn @ 2000-06-09 8:30 UTC (permalink / raw) To: obrien; +Cc: gcc >>>>> "David O'Brien" writes: David> The ChangeLog entry for this change is: David> revision 1.26 David> date: 1999/09/07 05:47:55; author: law; state: Exp; lines: +142 -130 David> Merge in gcc2-ss-010999 David> This lack of detail was very annoying as I spent a lot more time than David> needed to verify that the differences I noticed in gen* were intentional. David> The diff from 1.25 to 1.26 is large enough to explain the change. David> Looking at ``cvs log gengenrtl.c'' I was unable to find any details on David> the "gcc2-ss-010999" branch. What you list above is the CVS entry, not the ChangeLog entry. The entry in ChangeLog.2 says: * Merge from gcc2 snapshot Jan 9, 1999. See FSFChangeLog for details. Did you check FSFChangeLog (which contains the ChangeLog entries from the gcc2 development which was occurring in parallel with EGCS? The actual various ChangeLog files are the historical repository, not CVS log entries. David ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Conerned about lack of detail in ChangeLog/commit messges 2000-06-09 8:30 ` David Edelsohn @ 2000-06-09 8:51 ` David O'Brien 2000-06-09 9:13 ` Nick Burrett 0 siblings, 1 reply; 107+ messages in thread From: David O'Brien @ 2000-06-09 8:51 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc On Fri, Jun 09, 2000 at 11:30:21AM -0400, David Edelsohn wrote: > David> The diff from 1.25 to 1.26 is large enough to explain the change. > David> Looking at ``cvs log gengenrtl.c'' I was unable to find any details on > David> the "gcc2-ss-010999" branch. > > What you list above is the CVS entry, not the ChangeLog entry. > The entry in ChangeLog.2 says: > > * Merge from gcc2 snapshot Jan 9, 1999. See FSFChangeLog for > details. Sorry, I was under the impression (from what I've seen in other CVS commit messages) that the ChangeLog text is in the commit message. IMHO CVS logs are much easier to use to find the notes on a change than the ChangeLog's. GCC ChangeLog's do not use a consistent date format, thus it is time consuming to find the entry you are looking for as searching in your favorite viewer isn't as good as it could be. Nor does this ChangeLog entry contain the name of the modified file as it should. In this case, I could not use any of the CVS message text in searching for the ChangeLog entry except for the word "Merge". > Did you check FSFChangeLog (which contains the ChangeLog entries from the > gcc2 development I did not. I forgot that there was a FSFChangeLog vs. just ChangeLog. I guess I'm just used to the other projects who's CVS repo I work with. There is an emphasis on detail in commit messages to assist people in finding out about changes. I'm surprised the message above didn't at least tell people to see the FSFChangeLog (and give the applicable date range) for details on the changes. > The actual various ChangeLog files are the historical repository, not > CVS log entries. Yes I know. IMHO now that the world has access to the CVS logs, they could be better used now. -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Conerned about lack of detail in ChangeLog/commit messges 2000-06-09 8:51 ` David O'Brien @ 2000-06-09 9:13 ` Nick Burrett 2000-06-09 9:21 ` David O'Brien 2000-06-11 6:38 ` Marc Espie 0 siblings, 2 replies; 107+ messages in thread From: Nick Burrett @ 2000-06-09 9:13 UTC (permalink / raw) To: obrien; +Cc: David Edelsohn, gcc "David O'Brien" <obrien@NUXI.com> writes: > On Fri, Jun 09, 2000 at 11:30:21AM -0400, David Edelsohn wrote: > > David> The diff from 1.25 to 1.26 is large enough to explain the change. > > David> Looking at ``cvs log gengenrtl.c'' I was unable to find any details on > > David> the "gcc2-ss-010999" branch. > > > > What you list above is the CVS entry, not the ChangeLog entry. > > The entry in ChangeLog.2 says: > > > > * Merge from gcc2 snapshot Jan 9, 1999. See FSFChangeLog for > > details. > > Sorry, I was under the impression (from what I've seen in other CVS > commit messages) that the ChangeLog text is in the commit message. IMHO > CVS logs are much easier to use to find the notes on a change than the > ChangeLog's. > > GCC ChangeLog's do not use a consistent date format, thus it is time > consuming to find the entry you are looking for as searching in your > favorite viewer isn't as good as it could be. Nor does this ChangeLog > entry contain the name of the modified file as it should. In this case, > I could not use any of the CVS message text in searching for the > ChangeLog entry except for the word "Merge". This would be easily resolvable if in future the ChangeLog date and e-mail header were included in the CVS commit messages. It would make things much easier to cross-reference since the CVS date is always going to be slightly different to the ChangeLog date. I'm not sure if CVSweb would cope very well with this though. > > > Did you check FSFChangeLog (which contains the ChangeLog entries from the > > gcc2 development > > I did not. I forgot that there was a FSFChangeLog vs. just ChangeLog. I > guess I'm just used to the other projects who's CVS repo I work with. > There is an emphasis on detail in commit messages to assist people in > finding out about changes. I'm surprised the message above didn't at > least tell people to see the FSFChangeLog (and give the applicable date > range) for details on the changes. Perhaps it would have been better to include the FSFChangeLog directly into the ChangeLog under a single entry in the same way that is done for older branches. It's a bit late in the day for that though. > > The actual various ChangeLog files are the historical repository, not > > CVS log entries. > > Yes I know. IMHO now that the world has access to the CVS logs, they > could be better used now. I think it is much easier to look at a ChangeLog than look at the CVS logs for individual files. The `cvs log' has to keep on being re-generated, the ChangeLog is there, fast to access, and provides a good overview of all files changed, rather than just a few. Nick. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Conerned about lack of detail in ChangeLog/commit messges 2000-06-09 9:13 ` Nick Burrett @ 2000-06-09 9:21 ` David O'Brien 2000-06-11 6:38 ` Marc Espie 1 sibling, 0 replies; 107+ messages in thread From: David O'Brien @ 2000-06-09 9:21 UTC (permalink / raw) To: Nick Burrett; +Cc: gcc On Fri, Jun 09, 2000 at 05:13:08PM +0100, Nick Burrett wrote: > I think it is much easier to look at a ChangeLog than look at the CVS logs > for individual files. It might help if the date format for ChangeLog entries were standardized upon. > The `cvs log' has to keep on being re-generated, the ChangeLog is > there, fast to access, and provides a good overview of all files > changed, rather than just a few. I love my DSL, what can I say. :-) I do see your point. But, I am usually doing the opposite -- I just want to know about the chagnes to a single file. I find that a single file's change can get lost in the sometimes huge ChangeLog entries. -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Conerned about lack of detail in ChangeLog/commit messges 2000-06-09 9:13 ` Nick Burrett 2000-06-09 9:21 ` David O'Brien @ 2000-06-11 6:38 ` Marc Espie 1 sibling, 0 replies; 107+ messages in thread From: Marc Espie @ 2000-06-11 6:38 UTC (permalink / raw) To: gcc Yeah, gcc doesn't make a sensible utilisation of cvs, does it ? At least it's somewhat different from most other projects that use it that I know. The proposal of generating the cvs logs from the Changelog is somewhat backwards. It would probably be much, much simpler to generate a ChangeLog out of cvs commit messages. In fact, this is how other projects usually do it. Cvs does yield fairly nice commit messages. That would solve one specific problem: all files changed would be automatically mentioned in the commit message. The format can be tweaked afterwards to be as compliant with the Changelog entry as one wishes... In fact, I would very much prefer having the Changelog match the committed date, not some other somewhat artificial dates. There are lots of other ways to refer to a patch, the entry in the gcc-patches archive comes to mind. And David is quite correct that using the ChangeLog to browse through the history of one file is a pain... One loses most of the features that make cvs useful. For instance, `cvs annotate' is almost useless on gcc, since it is very hard to go back from gcc revisions to Changelog entry. I understand that this is somewhat hard to change, but consider it. There might be a good reason why other projects are actually USING cvs for day-to-day work, might there not ? :) ^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH] rs6000.c ELF bits inclusion @ 2001-05-02 18:21 David O'Brien 2001-05-02 20:07 ` David Edelsohn 2001-05-03 13:17 ` David O'Brien 0 siblings, 2 replies; 107+ messages in thread From: David O'Brien @ 2001-05-02 18:21 UTC (permalink / raw) To: gcc W/o this change one must include config/svr4.h rather than config/elfos.h, which is just wrong on BSD hosts as config/svr4.h contains bits specific to that platform vs. the generic ELF object format. 2001-05-02 David O'Brien <obrien@FreeBSD.org> * config/elfos.h, config/rs6000/rs6000.c: Use USING_ELFOS_H rather than USING_SVR4_H as the code is ELF specific, not SVR4 platform specific. Index: config/elfos.h =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/elfos.h,v retrieving revision 1.25.2.1 diff -u -r1.25.2.1 elfos.h --- elfos.h 2001/04/16 18:25:40 1.25.2.1 +++ elfos.h 2001/05/03 01:19:09 @@ -21,6 +21,9 @@ the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +/* Define a symbol indicating that we are using elfos.h. */ +#define USING_ELFOS_H + /* The prefix to add to user-visible assembler symbols. For ELF systems the convention is *not* to prepend a leading Index: config/rs6000/rs6000.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v retrieving revision 1.167.2.2 diff -u -r1.167.2.2 rs6000.c --- rs6000.c 2001/05/02 21:34:15 1.167.2.2 +++ rs6000.c 2001/05/03 01:19:10 @@ -75,7 +75,7 @@ get the address of the GOT section */ int rs6000_pic_labelno; -#ifdef USING_SVR4_H +#ifdef USING_ELFOS_H /* Which abi to adhere to */ const char *rs6000_abi_name = RS6000_ABI_NAME; @@ -442,7 +442,7 @@ } } -#ifdef USING_SVR4_H +#ifdef USING_ELFOS_H switch (rs6000_sdata) { case SDATA_NONE: fprintf (file, "%s -msdata=none", start); start = ""; break; @@ -7497,7 +7497,7 @@ Do not define this macro if you put all constants in the read-only data section. */ -#ifdef USING_SVR4_H +#ifdef USING_ELFOS_H void rs6000_select_rtx_section (mode, x) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH] rs6000.c ELF bits inclusion 2001-05-02 18:21 [PATCH] rs6000.c ELF bits inclusion David O'Brien @ 2001-05-02 20:07 ` David Edelsohn 2001-05-02 20:32 ` David O'Brien 2001-05-03 13:17 ` David O'Brien 1 sibling, 1 reply; 107+ messages in thread From: David Edelsohn @ 2001-05-02 20:07 UTC (permalink / raw) To: obrien; +Cc: gcc > W/o this change one must include config/svr4.h rather than > config/elfos.h, which is just wrong on BSD hosts as config/svr4.h > contains bits specific to that platform vs. the generic ELF object > format. What do you mean by "contains bits specific to that platform"? SVR4 is not a platform? For PowerPC, the only defined ABIs are PowerOpen (AIX and related to Darwin) and SVR4 (including eABI). eABI is a derivative of SVR4. There are no other ABIs. What other "generic" ELF object format is FreeBSD for PowerPC using that SVR4 is a conflict? David ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH] rs6000.c ELF bits inclusion 2001-05-02 20:07 ` David Edelsohn @ 2001-05-02 20:32 ` David O'Brien 2001-05-02 20:52 ` David Edelsohn 0 siblings, 1 reply; 107+ messages in thread From: David O'Brien @ 2001-05-02 20:32 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc On Wed, May 02, 2001 at 11:06:57PM -0400, David Edelsohn wrote: > > W/o this change one must include config/svr4.h rather than > > config/elfos.h, which is just wrong on BSD hosts as config/svr4.h > > contains bits specific to that platform vs. the generic ELF object > > format. > > What do you mean by "contains bits specific to that platform"? > SVR4 is not a platform? For PowerPC, the only defined ABIs are PowerOpen > (AIX and related to Darwin) and SVR4 (including eABI). eABI is a > derivative of SVR4. There are no other ABIs. What other "generic" ELF > object format is FreeBSD for PowerPC using that SVR4 is a conflict? Did you look at config/svr4.h??? #define WORD_SWITCH_TAKES_ARG(STR) \ (DEFAULT_WORD_SWITCH_TAKES_ARG (STR) \ && strcmp (STR, "Tdata") && strcmp (STR, "Ttext") \ && strcmp (STR, "Tbss")) No BSD ELF implementation supports these. #undef ASM_SPEC #define ASM_SPEC \ "%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}" This ASM spec is wrong. #define MD_EXEC_PREFIX "/usr/ccs/bin/" #define MD_STARTFILE_PREFIX "/usr/ccs/lib/" These MD spec are *WAY* wrong. This is a SVR4 _platform_ setting. Where in any ELF ABI is this spec specified? /* Provide a LIB_SPEC appropriate for svr4. Here we tack on the default standard C library (unless we are building a shared library). */ #undef LIB_SPEC #define LIB_SPEC "%{!shared:%{!symbolic:-lc}}" As the comment says, "appropriate for svr4", not all ELF platforms and certainly not FreeBSD. /* Provide an ENDFILE_SPEC appropriate for svr4. Here we tack on our own ... #define ENDFILE_SPEC "crtend.o%s %{pg:gcrtn.o%s}%{!pg:crtn.o%s}" Again, this is a bogus setting to force down ever ELF implementations throat. I need this one "%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s", and why should I have to #undef the world? /* Gcc automatically adds in one of the files /usr/ccs/lib/values-Xc.o, /usr/ccs/lib/values-Xa.o, or /usr/ccs/lib/values-Xt.o for each final link step (depending upon the other gcc options selected, such as -traditional and -ansi). These files each contain one (initialized) copy of a special variable called `_lib_version'. Each one of these files has `_lib_version' initialized to a different (enum) value. The SVR4 library routines query the value of `_lib_version' at run to decide how they should behave. Specifically, they decide (based upon the value of `_lib_version') if they will act in a strictly ANSI conforming manner or not. */ #undef STARTFILE_SPEC #define STARTFILE_SPEC "%{!shared: \ I won't even go into how this is very much a system implimentation setting is only appropriate for "true-blue" generic SVR4 implementations. /* Define the actual types of some ANSI-mandated types. (These definitions should work for most SVR4 systems). */ systems => platforms to me. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH] rs6000.c ELF bits inclusion 2001-05-02 20:32 ` David O'Brien @ 2001-05-02 20:52 ` David Edelsohn 2001-05-03 0:39 ` David O'Brien 0 siblings, 1 reply; 107+ messages in thread From: David Edelsohn @ 2001-05-02 20:52 UTC (permalink / raw) To: obrien; +Cc: gcc Isn't this a question of whether config/svr4.h assumes to much? Why is the right solution to change rs6000.c? Maybe it is or maybe it isn't. To me this is a broader design question than FreeBSD relying directly upon elfos.h and sweeping the changes under the rug. config/freebsd.h is duplicating pieces of config/svr4.h. This causes a maintenance problem. Is there no way to separate the system-specific pieces of config/svr4.h from the ABI-specific pieces so that FreeBSD could shared the latter with other SVR4-based system? David ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH] rs6000.c ELF bits inclusion 2001-05-02 20:52 ` David Edelsohn @ 2001-05-03 0:39 ` David O'Brien 0 siblings, 0 replies; 107+ messages in thread From: David O'Brien @ 2001-05-03 0:39 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc On Wed, May 02, 2001 at 11:52:33PM -0400, David Edelsohn wrote: > Isn't this a question of whether config/svr4.h assumes to much? Well... it used to, but that's why elfos.h was created. The object format is named "ELF", not "SVR4" (or "SYSV4"). Thus the generic object file format specifications were pulled out of config/svr4.h. I(FreeBSD) am not an AT&T/USL/NOVELL/SCO/CALDERA OS. I don't follow their file system layouts, nor their command-line options. I do share their object file format. Ie. the ELF gABI does apply to me and SVR4. Thus I feel "elfos" is a fine name for the object file bits than "svr4", but I really don't care what you call it. As long as there is a difference between object file bits and system/platform implementation bits. `elfos.h' isn't perfect yet, as it still has too much of svr4.h left in it, but I hope to clean up the CVS conflicts soon in my elfos.h where I fixed this. (also there are things in elfos.h that need to be in <arch>/elf.h, as alpha/elf.h has to undo thing in elfos.h) It is my strong opinion that every arch should have a config/<arch>/elf.h header also, to teak things in the applicable ELF psABI. We have this for alpha and i386 (although it would be very nice to move config/i386/i386elf.h to config/i386/elf.h, so that the rule is every ELF platform includes "elfos.h ${platform}.h ${arch}/elf.h ${arch}/${platform}.h". > Why is the right solution to change rs6000.c? In this case, because rs6000.c shouldn't care that it is being compiled for an AT&T/USL/NOVELL/SCO/CALDERA OS, but rather an ELF binary file format one. > maybe it isn't. To me this is a broader design question than FreeBSD > relying directly upon elfos.h and sweeping the changes under the rug. Actually many things include config/svr4.h and then undoes what svr4.h does. This is simply because many of the maintainers haven't yet cleaned up their files. The gcc/config/ header include spaghetti is still alive and I untangle it when I discover it and it is easy for me to test that I have not problem something in the untangle. > config/freebsd.h is duplicating pieces of config/svr4.h. If they are line-for-line duplications, then the bits should be moved to elfos.h if they are truly generic ELF related. Otherwise there is no big deal in this -- FreeBSD sits _beside_ SVR4 as a target. > Is there no way to separate the > system-specific pieces of config/svr4.h from the ABI-specific pieces so > that FreeBSD could shared the latter with other SVR4-based system? Yes, elfos.h and <arch>/elf.h. Is there some reason this is not suffient? -- -- David (obrien@FreeBSD.org) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH] rs6000.c ELF bits inclusion 2001-05-02 18:21 [PATCH] rs6000.c ELF bits inclusion David O'Brien 2001-05-02 20:07 ` David Edelsohn @ 2001-05-03 13:17 ` David O'Brien 2001-05-03 16:04 ` David Edelsohn 1 sibling, 1 reply; 107+ messages in thread From: David O'Brien @ 2001-05-03 13:17 UTC (permalink / raw) To: gcc, David Edelsohn On Wed, May 02, 2001 at 06:21:28PM -0700, David O'Brien wrote: > 2001-05-02 David O'Brien <obrien@FreeBSD.org> > > * config/elfos.h, config/rs6000/rs6000.c: Use USING_ELFOS_H rather than > USING_SVR4_H as the code is ELF specific, not SVR4 platform specific. This patch allows me to do what I need. Are you OK with it, or is there another way you would like to see the problem solved? I really do not want to include config/svr4.h. -- -- David (obrien@NUXI.com) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH] rs6000.c ELF bits inclusion 2001-05-03 13:17 ` David O'Brien @ 2001-05-03 16:04 ` David Edelsohn 2001-05-03 19:11 ` David O'Brien 0 siblings, 1 reply; 107+ messages in thread From: David Edelsohn @ 2001-05-03 16:04 UTC (permalink / raw) To: obrien; +Cc: gcc >>>>> "David O'Brien" writes: David> This patch allows me to do what I need. Are you OK with it, or is there David> another way you would like to see the problem solved? I really do not David> want to include config/svr4.h. I do not believe that it is productive for FreeBSD to have its own, slightly different ABI. FreeBSD likely will discourage more potential users by being slightly incompatible than it gains for any perceived improvement over the standard. This design argument does not seem to be effective with you. "... allows me to do what I need" is not a very compelling argument that a patch is correct or should be approved, IMHO. From my perspective, it seems that you expediently want to solve the symptom of your problem and not your problem. Because this patch is small and localized and this discussion no longer seems to be productive, I am not going to object to the rs6000.c change. I suspect that you will have to return to this issue again (and again) and eventually will need to solve it correctly. Someone else with authority for config/elfos.h needs to approve that part of the change. David ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH] rs6000.c ELF bits inclusion 2001-05-03 16:04 ` David Edelsohn @ 2001-05-03 19:11 ` David O'Brien 0 siblings, 0 replies; 107+ messages in thread From: David O'Brien @ 2001-05-03 19:11 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc On Thu, May 03, 2001 at 07:03:53PM -0400, David Edelsohn wrote: > >>>>> "David O'Brien" writes: > > David> This patch allows me to do what I need. Are you OK with it, or is there > David> another way you would like to see the problem solved? I really do not > David> want to include config/svr4.h. > > I do not believe that it is productive for FreeBSD to have its > own, slightly different ABI. I do not feel FreeBSD has its own "slightly different ABI" any more than Linux or AIX does. Linux and FreeBSD, at least, both break ever psABI I know of by not using the defined name of the dynamic interrupter specified. For PowerPC FreeBSD will follow either the ABI or eABI as specified in "PowerPC Processor ABI Supplement - Sept. 1995". (if you know of a better PPC psABI, please let me know) Maybe we should agree on some terms to help the discussion. Do you consider what the gabi4.1pdf (System V Application Binary Interface) from www.sco.com and "PowerPC Processor ABI Supplement - Sept. 1995" describes to be the ELF or SVR4 ABI? Both of these uses "SVR4", however wider usage [here] seems different. "ELF: From The Programmer's Perspective" by Hongjiu Lu, says: The Executable and Linking Format (ELF) is a binary format originally developed and published by UNIX System Laboratories (USL). It is the default binary format for the executable files used by SVR4 and Solaris 2.x. I interrupt this to mean Lu considers the binary format and ABI to be named "ELF" and SVR4 a consumer of it (having been invented by its maker). If you want to call the ABI "SVR4", what term should we use to describe the Unix system from USL? As I pointed out in another email, things like "#define SCCS_DIRECTIVE" and linker command line options are not specified in any gABI or psABI document I know of and describes an attribute not of an ABI, but a particular Unix system. When elfos.h was created from svr4.h, I thought GCC developers in general had agreed that "svr4" was the Unix system, and "elf" to refer to the general ABI and object format attributes. If this is not the case, give me two terms and lets make the existing elfos.h be svr4.h and the existing svr4.h to be svr4-implementation.h or what ever two terms you give me. > FreeBSD likely will discourage more potential users by being slightly > incompatible than it gains for any perceived improvement over the > standard. This design argument does not seem to be effective with you. The attributes in the various FreeBSD headers describe attributes of FreeBSD systems such as the name of our crt.o file is crt1.o, our linker uses -Bshareable and -Bsymbolic, but not -p, our dynamic linker is /usr/libexec/ld-elf.so.1, we expect "__PIC__" to be defined if -fPIC was given on the command line, we don't like DEFAULT_PCC_STRUCT_RETURN, or WCHAR_UNSIGNED. Do you consider these to be part of a standard, or just platform implementation details? (granted the dynamic linker is address in the above ABI documents) > "... allows me to do what I need" is not a very compelling > argument that a patch is correct or should be approved, IMHO. Why not? I have a need of greater generality that currently exists. Because there are an infinite amount of hours for anyone to work on GCC, people are only going to put time into things that "scratch itches" You admitted that you know there are something in rs6000.h that better belong in aix.h. Why haven't you moved them there yet? Because the need isn't [yet] great enough to spend the time on it. > From my > perspective, it seems that you expediently want to solve the symptom of > your problem and not your problem. I feel my problem is many of the GCC config headers were written under the assumption only the vendor's OS is the only OS in existence that runs on the HW. Things have gotten better over time, but alpha/alpha.h still assumes it describes OSF/1. rs6000/rs6000.h still has assumptions of AIX in it. What do you feel is my problem? > Because this patch is small and localized and this discussion no > longer seems to be productive, I would like to make it productive. > I suspect that you will have to return to this issue again (and > again) and eventually will need to solve it correctly. Explicitly, what is the correct way to solve it? -- -- David (obrien@FreeBSD.org) ^ permalink raw reply [flat|nested] 107+ messages in thread
end of thread, other threads:[~2001-05-03 19:11 UTC | newest] Thread overview: 107+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-09-14 19:32 FreeBSD 4.0 Wes Morgan 1999-09-14 20:08 ` Richard Henderson 1999-09-15 2:00 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Richard Henderson 1999-09-14 22:34 ` Loren James Rittle 1999-09-14 23:00 ` Zack Weinberg 1999-09-14 23:14 ` David O'Brien 1999-09-15 0:25 ` Zack Weinberg 1999-09-15 0:56 ` David O'Brien 1999-09-15 1:21 ` Andreas Schwab 1999-09-15 1:40 ` David O'Brien 1999-09-15 2:23 ` Andreas Schwab 1999-09-15 3:11 ` David O'Brien 1999-09-15 3:52 ` Andreas Schwab 1999-09-30 18:02 ` Andreas Schwab 1999-09-30 18:02 ` David O'Brien 1999-09-30 18:02 ` Andreas Schwab 1999-09-20 3:58 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 1999-09-30 18:02 ` Andreas Schwab 1999-09-30 18:02 ` David O'Brien 1999-09-15 1:17 ` David O'Brien 1999-09-15 9:23 ` Zack Weinberg 1999-09-15 10:24 ` David O'Brien 1999-09-16 14:48 ` Richard Henderson 1999-09-30 18:02 ` Richard Henderson 1999-09-30 18:02 ` David O'Brien 1999-09-20 4:20 ` Jeffrey A Law 1999-09-21 6:33 ` The USER_H issue Marc Espie 1999-09-30 18:02 ` Marc Espie 1999-09-30 18:02 ` FreeBSD 4.0 Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 1999-09-20 4:34 ` Jeffrey A Law 1999-09-20 9:26 ` Zack Weinberg 1999-09-20 9:55 ` Jeffrey A Law 1999-09-20 10:17 ` Zack Weinberg 1999-09-20 10:38 ` Richard Earnshaw 1999-09-20 11:02 ` Zack Weinberg 1999-09-30 18:02 ` Zack Weinberg 1999-09-20 11:39 ` Horst von Brand 1999-09-20 11:49 ` Chris G. Demetriou 1999-09-30 18:02 ` Chris G. Demetriou 1999-09-30 18:02 ` Horst von Brand 1999-09-30 18:02 ` Richard Earnshaw 1999-09-23 8:51 ` Jeffrey A Law 1999-09-23 9:13 ` Pending Projects Bruce Korb 1999-09-30 18:02 ` Bruce Korb 1999-09-30 18:02 ` FreeBSD 4.0 Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 1999-09-30 18:02 ` Zack Weinberg 1999-09-15 2:00 ` Jeffrey A Law 1999-09-15 2:25 ` David O'Brien 1999-09-15 2:33 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien [not found] ` <37DFAD27.3E6A25E3@datadesign.com> [not found] ` <199909152042.PAA29374@latour.rsch.comm.mot.com> 1999-09-15 14:26 ` Bruce Korb 1999-09-15 17:10 ` Jeffrey A Law 1999-09-16 1:46 ` Marc Espie 1999-09-16 6:57 ` Jeffrey A Law 1999-09-16 7:41 ` Marc Espie 1999-09-16 7:55 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Bruce Korb 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` David O'Brien 1999-09-15 1:59 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Zack Weinberg 1999-09-15 7:42 ` Wes Morgan 1999-09-30 18:02 ` Wes Morgan 1999-09-30 18:02 ` Loren James Rittle 1999-09-30 18:02 ` Wes Morgan 1999-09-16 12:42 Mike Stump 1999-09-30 18:02 ` Mike Stump 1999-09-16 13:13 Mike Stump 1999-09-16 13:36 ` Marc Espie 1999-09-16 13:54 ` Jeffrey A Law 1999-09-30 18:02 ` Jeffrey A Law 1999-09-30 18:02 ` Marc Espie 1999-09-30 18:02 ` Mike Stump 1999-09-20 13:43 Mike Stump 1999-09-30 18:02 ` Mike Stump 2000-06-08 12:42 Conerned about lack of detail in ChangeLog/commit messges David O'Brien 2000-06-08 15:18 ` Martin v. Loewis 2000-06-09 8:30 ` David Edelsohn 2000-06-09 8:51 ` David O'Brien 2000-06-09 9:13 ` Nick Burrett 2000-06-09 9:21 ` David O'Brien 2000-06-11 6:38 ` Marc Espie 2001-05-02 18:21 [PATCH] rs6000.c ELF bits inclusion David O'Brien 2001-05-02 20:07 ` David Edelsohn 2001-05-02 20:32 ` David O'Brien 2001-05-02 20:52 ` David Edelsohn 2001-05-03 0:39 ` David O'Brien 2001-05-03 13:17 ` David O'Brien 2001-05-03 16:04 ` David Edelsohn 2001-05-03 19:11 ` David O'Brien
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).