Date: Tue, 19 Oct 1999 02:07:57 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Will Andrews <andrews@TECHNOLOGIST.COM> Cc: current@FreeBSD.ORG Subject: Re: -CURRENT `make world` fails.. (ucontext.h?) Message-ID: <380B53ED.20B3DC5C@newsguy.com> References: <XFMail.991018123824.andrews@TECHNOLOGIST.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
[removing cc's, since I addressed them in another message in another
thread in another list :]
Will Andrews wrote:
>
> Yes, that's how I did it. Actually, I had 3.3-RELEASE.. I downloaded the entire
If you had 3.3-RELEASE, you wouldn't need a new loader to load the
-current kernel. That's not true of someone who had 3.1-RELEASE.
> > Now, aout_freebsd.c (and possibly other files) in
> > sys/boot/i386/libi386 includes sys/param.h, which, in turn, includes
> > sys/signal.h. The later requires machine/ucontext.h, which is not
> > present. Why the newer signal.h is found but not ucontext.h, I'll
> > find out shortly (I hope :). For now, I'm working with the
> > hypothesis of a "file.h" instead of <file.h> #include.
>
> Yes, I thought the <machine/ucontext.h> was the problem. Is
> "machine/ucontext.h" under /usr/src somewhere? I thought I saw one, but
> couldn't seem to finger its precise path.
Actually, now that I spent a few minutes witht he code, it's obvious
that I was way short-sighted in this. The analysis above is too
naive, and, to be blunt, dumb. :-) Obviously, /usr/src/sys/machine/*
cannot be found, because it does not exist. /usr/include/machine/*
is generated from /usr/src/sys/${MACHINE_ARCH}/include. The makefile
uses -I so that <sys/*> files will be found under /usr/src/sys
(well, not exactly -- it uses a relative path, but that's the gist
of it :), but the <machine/*> files included by those cannot be
found.
Thus, we have a situation in which some of the include files are the
latest (<sys/*.h>), and some are not (<machine/*.h>).
The problem is triggered by <machine/ucontext.h>, but it could have
been triggered by a number of other files. It's just not a simple
problem to solve. :-(
> Like I said above, a -CURRENT kernel may have problems with a -STABLE world.
>
> I'm honestly not fully aware of the dependencies regarding the signal changes
> (i.e., ucontext.h), so my thoughts may be completely wrong. :-)
>
> Comments?
You ought to say that a -STABLE world will have problems with a
-CURRENT kernel. The kernel ought to be immune to -STABLE world's
problems. :-) In a perfect world, anyway. :-) Anyway, there are
problems a -STABLE world will have with a -CURRENT kernel, but they
are not likely to be crippling (ie, you should be able to make world
after booting the new kernel). One thing that *can* bite is the use
of klds. Bad ju ju may result from the use of old klds with a new
kernel.
--
Daniel C. Sobral (8-DCS)
dcs@newsguy.com
dcs@freebsd.org
"I always feel generous when I'm in the inner circle of a
conspiracy to subvert the world order and, with a small group of
allies, just defeated an alien invasion. Maybe I should value myself
a little more?"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?380B53ED.20B3DC5C>