Here are some hints about how to approach testing after nontrivial changes to
glibc have been done.

---

First step is having the build a glibc complete.  This is actually more
difficult than one might expect, as it involves (towards the end of the build
process; unless you are cross-building, of course), that the newly created
libraries and loader actually work: they're used to run the `rpcgen`
program.  If that step doesn't succeed, it'll look similar to this:

    [...]
    CPP='gcc -E -x c-header' [...]/build/elf/ld.so.1 --library-path [...] [...]/build/sunrpc/rpcgen [...]
    Segmentation fault

---

If building glibc succeeds, the next thing to try is running the test suite, or
parts of it.

Here is a list of known failures:

[TODO].

---

Make sure static linking is working OK at all.  The `elf/sln` program (a
stripped-down `ln` that is statically linked) in the glibc build ought to test
that.  Also, static linking under various conditions will already have been
tested when running the test suite, especially in `elf/` and `dlfcn/`.

Make sure static linking with cthreads is working.  If you can get an
`ext2fs.static` compiled and linked against the new glibc, that is good.

[TODO].

Then debug its startup as a normal program on your working hurd.

    $ [...]/ext2fs.static --help
    [...]

Then try its full server startup.

    $ settrans -ca node [...]/ext2fs.static <BACKEND>
    $ cd node/
    [...]

Make sure dynamic linking for servers is working.  If you haven't broken the
ABI, you can just use an existing `/hurd/foobar` binary, started the way
glibc's `testrun.sh` does it.

[TODO]: Is this the correct way to do that?

    $ settrans -ca node [glibc]/build/testrun.sh /hurd/ext2fs <BACKEND>
    $ cd node/
    [...]

---

Test it in a [[subhurd]].

---

Test it on a real system.

---

Sources:

* <http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00038.html>
* [[Thomas_Schwinge|tschwinge]]'s mind