Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!ukc!dcl-cs!strath-cs!jim
From: jim@strath-cs.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <674@stracs.cs.strath.ac.uk>
Date: Fri, 28-Aug-87 06:51:40 EDT
Article-I.D.: stracs.674
Posted: Fri Aug 28 06:51:40 1987
Date-Received: Tue, 1-Sep-87 05:44:14 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <2877@ulysses.homer.nj.att.com> <8195@mimsy.UUCP>
Reply-To: jim@cs.strath.ac.uk
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 24

In article <8195@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>........................ --one should be able to build experimental
>kernels without reference to /usr/include.

Indeed. This is not always the case however. The last time our 4.2
kernel was substantially hacked, I was bitten by an obscure bug caused
by a mismatch of the include files. The changed include files were under
/sys, but the *copies* in /usr/include were left untouched -- my plan
was to get the new kernel stable, update the include files and then
recompile any user programs.

What happened was that a C program (genassym.c) was used to generate a
file of symbolic constants used by the assembler in assembling locore.s.
This pulled in values from /usr/include and not /sys! The result was
the generated assembler file had the wrong values for some fundamental
constants like the size of the user area. Needless to say, this meant
locore.o was screwed up. The kernel would compile OK, but it would fall
over when it 'forked' init...... Even compiling a new kernel from scratch
did not cure this.

[This is a bit of a digression from discussing symbolic links, which has
become a little tiresome.]

		Jim