Subject: glibc v1.09 problems
To: None <netbsd-bugs@NetBSD.ORG, netbsd-users@NetBSD.ORG, current-users@NetBSD.ORG,>
From: Mathew Patton <firstname.lastname@example.org>
Date: 03/20/1996 22:43:59
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
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
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__))
8. #define __NORETURN
9. #define __CONSTVALUE
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;
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
and which in turn loads ./stddef.h for the very first time, size_t does not
get defined DESPITE the
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
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'
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.