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 involves at one point that the newly created libraries and loader actually work. (Unless you are cross-building, of course). 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 $ 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 $ cd node/ [...] ---- Test it in a subhurd. See [[SubhurdHowto]] for the basics about subhurds. ---- Test it on a real system. ---- Sources: * * [[ThomasSchwinge]]'s mind