From ed6a4c4a2fca34c5bb1428dd9226d4c8bf703d5f Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 15 Feb 2007 15:24:00 +0000 Subject: none --- Hurd/DebuggingGlibc.mdwn | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 Hurd/DebuggingGlibc.mdwn (limited to 'Hurd') 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: + +* +* [[ThomasSchwinge]]'s mind -- cgit v1.2.3