Simon Marlow writes:
> 1) The new library seems to use __USE_BSD rather than __FreeBSD__; I
> had to change one "ifndef" to get it through "gmake boot".
Huh? Which library?
Just about all of them; hopping into /usr/include and doing a "grep
USE_BSD" gives a whole mess of files: grp,h, math.h, netdb.h,
setjmp.h, signal,h, stdio.h, stdlib.h, string.h, termios.h, unistd.h.
Similarly, doing a "grep FreeBSD" in the same directory produces
nothing.
Let me be a bit more specific: during "gmake boot" the compile crashed
with the following message:
makeinfo.c: In function `cm_infoinclude':
makeinfo.c:6344: conflicting types for `sys_errlist'
/usr/include/stdio.h:221: previous declaration of `sys_errlist'
The definition in "makeinfo.c" surrounds this definition with a
"ifndef __FreeBSD__" test. The definition in /usr/include/stdio.h is
surrounded by a "ifdef __USE_BSD" test. The two were sufficiently
similar that I theorized that the name of the flag had changed
somehow. Changing the name of the if statement in makeinfo.c to
"ifndef __USE_BSD" allowed it to continue to compile.
> 2) The full pathname to cpp had changed; I had to modify "mkdependHS"
> by hand.
re-configure instead: other things may have changed.
Is it safe to copy the results of the "gmake boot" into my binary
directory? The problem is that the make file is going off of the
"mkdependHS" in the previous build, which is in installed in my binary
directory there.
> Then I got to the biggie; I am not sure what to do here. The "gmake
> boot" gives me lots and *lots* of errors of the following form:
>
> /usr/include/sys/uio.h:37: macro or `#include' recursion too deep
> /usr/include/sys/uio.h:39: macro or `#include' recursion too deep
> /usr/include/sys/uio.h:47: macro or `#include' recursion too deep
> /usr/include/sys/uio.h:49: macro or `#include' recursion too deep
>
> This happened on lots of files. I suspect that, because of this, I
> get some undefined constant errors:
>
> main/Signals.c:143: (Each undeclared identifier is reported only once
> main/Signals.c:143: for each function it appears in.)
> main/Signals.c:143: parse error before `addr'
> main/Signals.c:150: `addr' undeclared (first use this function)
> main/Signals.c:150: parse error before `stks_space'
We don't have any RedHat 5 machines here (although apparently we're
going to be upgrading soon) so I can't reproduce this yet.
Your best bet is to try to track this down yourself - find out which
type in Signals.c isn't recognised (10-1 its a typedef that's either
changed name in RedHat 5 or moved to a different header file). I'm
not sure about the uio.h problem, it could be that one of our macros
is conflicting with a system header file.
Dumb me; I cut off the error one line too soon. The previous line
said:
main/Signals.c:143: `caddr_t' undeclared (first use this function)
which gives the name of the undeclared variable. Tracking this down
was a bit of a task; however, I found it in "sys/types.h", surrounded
by a "ifdef __USE_BSD" test. So, fine; I know that "__USE_BSD" is not
defined here. On the other hand, I don't know what to do about it. I
suppose I could simply take that definition out of the loop in the
types.h file; however, I don't know what else this would affect. I
could follow the "makeinfo.c" example and put the definition inside of
"Signals.c", surrounded by an "ifndef __USE_BSD" statement; however,
where else will it crop up?
So, again, I am at a loss; I don't quite know what to do. Any
suggestions?
Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb
