diff options
| -rw-r--r-- | Hurd/DebuggingGlibc.mdwn | 36 |
1 files changed, 36 insertions, 0 deletions
diff --git a/Hurd/DebuggingGlibc.mdwn b/Hurd/DebuggingGlibc.mdwn new file mode 100644 index 00000000..71573b0b --- /dev/null +++ b/Hurd/DebuggingGlibc.mdwn @@ -0,0 +1,36 @@ +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: + +* <http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00038.html> +* [[ThomasSchwinge]]'s mind |