glibc

Here are some hints about how to approach testing after nontrivial changes to glibc have been done.

First step is having the build of glibc succeed. This is actually more difficult than one might expect as it involves (towards the end of the build process -- unless you are cross-compiling, of course -- that the newly created libraries and loader actually work: they'll be used to run the rpcgen program. 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

Unless cross-compiling, the next thing you'll probably want to do is running the test suite, or parts of it.

There is a list of known failures.

When building the debian glibc, to save yourself a double-compilation, comment in debian/sysdeps/hurd-i386.mk the lines about xen. Then to avoid the whole testsuite, use:

DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage

To save even more build, stop the build after configure has run, and then you can restart the build of only libc.so and libc.a with:

cd build-tree/hurd-i386-libc
make lib

or of only libc.so with:

make objdir=$PWD/build-tree/hurd-i386-libc $PWD/build-tree/hurd-i386-libc/libc.so

or of the whole tree with:

cd build-tree/hurd-i386-libc
make

or of just one subdir with for instance:

make subdir=libpthread -C libpthread ..=../ objdir=$PWD/build-tree/hurd-i386-libc

(note that most subdirs need libc.so built)

In some cases, printing to stdout/stderr is problematic. One can use a kernel with kdb enabled, and mach_print to get messages on the console:

#include <mach/mach_traps.h>
...
    mach_print("foo\n");

If your mach_traps.h does not have the declaration, use:

extern void mach_print(const char *s);

This call does not support any formatting. You can use this kind of helper to format a message before passing to gnumach:

#include <mach/mach_traps.h>
#include <stdio.h>

static void myprintf(const char *fmt, ...)
{
  va_list ap;
  char buf[1024];
  va_start(ap, fmt);
  vsnprintf(buf, sizeof(buf), fmt, ap);
  mach_print(buf);
  va_end(ap);
}

If you've been doing simple changes to glibc functions that end up in libc.so, you may test them like this (like for a strerror_l implementation in this case):

$ LD_PRELOAD=./libc.so ./ld.so ./a.out 10 1073741928 de_DE.utf8
1073741928 (0x40000068): Computer bought the farm
1073741928 (0x40000068): Der Computer hat den Bauernhof erworben

You usually will only have luck using the new libc.so (from [glibc-build]/libc.so) in combination together with the new ld.so (from [glibc-build]/elf/ld.so):

$ LD_PRELOAD=./libc.so ./a.out 10 1073741928 de_DE.utf8
Killed
$ LD_PRELOAD=./libc.so /lib/ld.so ./a.out 10 1073741928 de_DE.utf8
Killed

Make sure static linking is working OK at all. Running the [glibc-build]/elf/sln program (a stripped-down ln that is statically linked) 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 BACKING_STORE
$ ls -l 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 BACKING_STORE
$ cd node/
[...]

Test it in a subhurd.

Test it on a real system.