blob: 71573b0b905203d870651094347da5e541bbccaa (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
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
|
