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>