I applogize to those who read bugs,users, and current as I've posted to 
all three but I think all three groups will derive some benefit.

I posted a question on -users about getting libstdc++.a for NetBSD v1.1 and 
was told by quite a few people to upgrade to -current since gcc 2.7.2 was 
more or less supported at that level.

Unfortunately that wasn't a real option so I bullheadedly compiled gcc 
2.7.2 on my NetBSD 1.1 box.  That was easy.  The fun started with an 
attempt to 
build glibc v1.09. (this is where -current people might be interested)

Turns out there are 4 problems with v1.09 that require a little fixing.

1) The NetBSD compile (actually i386-unknown-netbsd1.1) of gcc 2.7.2 does 
not support 
the symbols __NORETURN and __CONSTVALUE (note the case).  For 
__NORETURN, NetBSD uses __dead which remaps to __volatile.  That detail 
aside, note the following quote in glibc v1.09's misc/sys/cdefs.h file 
(lines 32-40 shortened and paraphrased):
/* ... In versions 2.5 and 2.6, the '__attribute__' syntax used below 
does not work properly */
1. #if __GNUC__ < 2 or < 2.5
2. #define __NORETURN __volatile
3. #define __CONSTVALUE __const
4. #elif __GNUC__ >2 or __GNUC_MINOR__ >= 7 /* Faith */ <---- note this,
5. #define __NORETURN __attribute__ ((__volatile__))
6. #define __CONSTVALUE __attribute__ ((__const__))
7. #else
8. #define __NORETURN
9. #define __CONSTVALUE
10.#endif

Line #4 is not only wrong, the 'OR' should be an 'AND' for the logic 
indicated in the comments to be acted upon but also the 'faith' appears 
to be a bit wishful.  Now it just may be that gcc 2.7.2 under Netbsd was 
not done correctly.  I don't have access to other platforms to see if 
this holds true.  In either case, gcc can not parse functions that are 
declared: void __NORETURN foo(...).  And there are a bunch of these in 
glibc files.  A change of the middle section to:

#define __NORETURN __volatile
#define __CONSTVALUE __const

works fine as far as I can tell.

2) conflicting deffinitions of sys_errlist[];
stdio.h in NetBSD calls for:
	extern const char *const sys_errlist[];
while glibc's stdio.h calls for:
	extern char *sys_errlist[];

I don't know which is more 'correct' but either way, this becomes a small 
but tangible porting issue.

3) possible logic error in glibc's stddef.h
Line 135-7 reads:
#if !(defined (__GNUG__) && defined (size_t))
#typedef __SIZE_TYPE__ size_t;
#endif

I have no idea where __GNUG__ comes from but be that as it may, I think
the 'size_t' in the #if statement should be '__size_t'.  I could be way 
wrong on this.

4) And now for the biggie which has 2 related parts.
When one of glibc's files includes <stdio.h> (which is in 
turn ./stdio/stdio.h) 
and which in turn loads ./stddef.h for the very first time, size_t does not 
get defined DESPITE the

#define __need_size_t
#include <stddef.h>

located in the stdio.h file.  Apparently with all the bizare #ifdef cases 
in stddef.h this particular sequence of includes does not set a flag 
correctly.  I havent' determined which one is the culprit as I don't know 
enough about the origin/use of these variables.  However, if stddef.h is 
first included (with __need_size_t defined) and then later stdio.h is 
included 
there is no problem.  I believe adequate proof is available by comparing the
./stdio/vfprintf.d and ./stdio/vprintf.d or ./stdio/vsnprintf.d files.

Of particular note is that vfprintf.d shows stddef.h included long before 
stdio.h, and has no problems compiling.  The latter two cases, 
however, include stdio.h first which in turn includes stddef.h and gcc  
proceeds to blow up with "can't parse errors" in stdio.h saying 'size_t' 
is unknown.

For part2 of this problem, I noticed that vfprintf.c, __vfscanf.c, and 
printf_fp.c in the stdio/ directory include <localinfo.h> whereas the others 
don't.  What is 
the rationalle for not including localinfo.h in the others?  in order to 
solve part1, I've tenativly modified each non-compiling file to include 
<localinfo.h> before <stdio.h> is included.  Amazingly, no problems pop 
up regarding 'size_t' being undefined.


I hope the above information proves useful in fixing the bugs or if they 
aren't 'bugs' proves useful to those doing teh porting of glibc v1.09 to 
NetBSD.  I will be happy to entertain further questions / comments as needed.