please test libio

[Roland McGrath]

The libc and hurd code has been ready to switch to libio for some time.
But it needs to be tested.

If you have had success building glibc for the hurd (i.e. you can either
cross-compile or natively compile libc, install it on your hurd, and run a
happy hurd), then please try building and testing the libio version.

The first step is just to build libc with libio enabled.  Do this just the
same way you have successfully built a normal hurd libc, but add
--enable-libio to the configure command.  If you have not done a successful
vanilla hurd libc build quite recently, then please do that first and
verify it works for you before attempting anything with libio.  (Anyone
serious about hacking libc should have two parallel build dirs from the
same libc sources, one with --enable-libio and one without.)

Then run make check on this libc build and compare those results to what
you got from make check on your non-libio build of libc.  We might as well
fix everything we can find with libc's own test programs before worrying
about anything else.

The step after that will be to build a hurd using this libc.  What I
recommend doing is setting up a second cross-compilation environment in
which you will install the libio universe.  For example, I am
cross-compiling on from Linux and have an `i586-gnu' cross-compilation
environment set up (with `make-cross') for my normal libc and hurd builds
(i.e. i586-gnu-gcc, /usr/i586-gnu/, etc).  I've now set up a second
cross-compilation environment for `i686-gnu'; after building my
libio-enabled libc and installing it into a new cross-install tree that
/usr/i686-bin/ points to (make a configparms file that sets install_root),
I simply configure a second hurd cross-build with --host=i686-gnu.

Once you have an install tree with the libio-based libc and hurd in it,
you'll have gotten as far as I have now, since I'm cross-compiling and
can't run a hurd to test on.  At this point you can start to do some basic
tests on the hurd built with libio.  First, just use LD_LIBRARY_PATH and
running the new libc's ld.so.1 directly to test some of the Hurd programs
you've built.  Simple utilities like showtrans will indicate if the basic
setup is working.  Next try /hurd/hello and /hurd/hello-mt.  First try just
running them with --help to make sure they get as far as running main.
Then try out /hurd/hello-mt as an active translator, i.e.:
    # settrans -a -c foo /bin/env LD_LIBRARY_PATH=/XX/lib /XX/lib/ld.so.1 
/XX/hurd/hello-mt
or something along those lines.

If all of that works splendidly, then you are ready to try to the boot
test.  That is, put your new install tree into a filesystem and try to boot
it as a sub-hurd.  If you don't have a scratch partition, you can just make
an ext2fs in a file and use that as the sub-hurd's virtual root disk in the
`boot' command.

Don't expect to be able to do anything with that hurd.  Your install tree
with just have the programs libc installs and the hurd programs,
so if all goes perfectly you'll be talking to /bin/shd.

When we've fixed everything in between so somebody gets this far, then come
back and talk to me about populating the system with binaries that work.
Either you get to recompile EVERYTHING (including bootstrap
cross-compiles), or you'll go back and do a whole different libc build and
we'll start on debugging the issues of the backward binary compatibility
support.  But all that can wait until we have all the aforementioned testing.