How PlashGlibc is built

There are two systems for building PlashGlibc:

The "integrated" build process. This is the current system. It was introduced by Story6. This patches the glibc build system to produce suitable libc.so and ld.so libraries directly.
The "separate" build process. This is the old system, from before Story6. It invokes glibc's normal build process, but ignores the libc.so and ld.so libraries it produces. Instead, it reuses most of the *.os object files it produces, and relinks them, adding some new code (which it compiles from C itself) and omitting some object files. Some object file symbols are renamed before linking, using objcopy.

Wrapping library calls

The main source of complication in building PlashGlibc is that some of its functions must be implemented in terms of glibc's normal version of that function. For example, PlashGlibc's fork() is a wrapper around glibc's normal fork() implementation. PlashGlibc's fork() clones the connection to the server before forking the process.

With the integrated build process, this is done by renaming the original versions of the calls, adding a "kernel_" prefix to the name. e.g. fork() becomes kernel_fork(). In most cases this is done by changing syscalls.list files (which cause syscall code to be generated by assembler files), but in some cases it requires changing glibc C files.

With the separate build process, linking happens in multiple steps:

First, Plash-specific object files are linked with glibc object files for system calls that are no longer exposed directly (fork.os etc.). This produces combined.os.
The Plash-specific code defines wrapper functions with new names, e.g. new_fork(). In this step, those symbols are renamed, using objcopy. new_fork() is renamed to fork(). All other symbols are hidden.
Lastly, the rest of the glibc object files are linked together with combined.os to produce libc.so.

Problems with the old, separate build process

There is a risk that relinking does not reproduce what glibc's build process does, and links with wrong options, producing a libc.so with subtle bugs.

Can't reuse Debian packaging for libc6.

When building the Plash-specific object files, the C code is compiled against installed libc header files rather than the header files in glibc's source tree. Firstly this is bad because of the dependency it introduces; this stops you from building glibc 2.4 on a system with 2.3.6 installed. Secondly, glibc's private headers contain some definitions not available in the public headers, such as architecture-specific stuff related to struct stat.