Making a dynamically-linked root

[Peter Jeremy]

On Mon, Jun 02, 2003 at 12:10:07PM -0700, Sean Chittenden wrote:
>On a different note regarding /rescue, would it be possible to add
>less(1) to the rescue set?

less needs libcurses which needs termcap which is in /usr.  less is
also non-trivial in size.  Why don't we just add emacs (or perl)?
Then we wouldn't need ls or cat or less or sh or ... :-)

>  In single user mode, scroll lock doesn't work

It does on every system I've ever used FreeBSD on - it's handled
inside syscons(4).  You might like to verify that your scroll lock
button is actually returning the keycode that syscons expects.

> and there's no way to read recent entries in UPDATING without
>cat(1) or head(1).

UPDATING is in /usr - by which time you should have cat(1) and head(1).
In any case, you can write a "good-enuf" tool to read files in sh:
	cat() { while read x; do echo $x; done < $1 }
(for extra points, make it correctly handle whitespace and pause every
screenful of output, using shell builtins only).

With a bit of thought, you should be able to read UPDATING from the
boot loader.

>  Lastly, on install, given the importance of having
>functioning binaries for /bin and /sbin, has it been considered to
>have the programs executed once before install to see if they can run,
>possibly with the -V flag?
>
>	 ./[progname] --test
>	 install [progname] /bin
>
>Having make bomb out after having the program run a "self test" that
>tests its ability to execute with ld would save many headaches.

What does 'see if they can run' cover?  Given lazy binding shared
libraries, it's quite possible for a program to manage to get to
main() and print out a message whilst being unable to actually do any
useful work because a critical shared library entry point is missing
for some reason.  Even without lazy binding, it's still non-trivial to
have "self test" code that validates even the "major" code paths (for
some definition of "major").

Peter