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. ---- Make sure static linking is working ok at all. The _elf/sln_ program in the glibc build ought to test that. 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. Then debug its startup as a normal program on your working hurd, i.e. just run it with _--help_. Then try its full server startup, i.e. _settrans -a_. 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. ---- Test it in a subhurd. ---- Test it on a real system. ---- Sources: * * [[ThomasSchwinge]]'s mind