Perform a Clipped Port
This log starts with some work for the general system port already having been done by another developer.
Preparation of a new glibc external
See the Debian 6 full port log for more details. Note that for Debian 9, apt-get source glibc applied the patches; debian/rules patch was probably a no-op.
Locate and see how glibc builds
apt-get source glibc cd glibc-2.24 debian/rules patch cd .. mv glibc-2.24 glibc-2.24-11 tar -z -c -f glibc-2.24-11.tar.gz glibc-2.24-11 cd glibc-2.24-11 debian/rules build |& tee build.out
The build failed. Needed to do apt-get build-dep glibc. This wanted makeinfo, but still failed, unable to find selinux/selinux.h a long way into the build. Since /usr/include/selinux/selinux.h existed, I tried
apt-get install linux-headers-4.9.0-3-all. This didn't help. I tried starting over, in case the selinux headers were supposed to have been copied into the tree; didn't help. Looked at other glibc external build comments, tried apt-get install gcc-multilib, because of the debian/include silliness. (Why bother if you're going to make symlinks?) This fixed the problem.
Run apt-get install texi2html to get makeinfo.
Create the glibc external
Follow the instructions. Note that parrot updates what it serves over HTTP from AFS every ten minutes.
Notes: the build system will warn but not fail if it doesn't find the glibc version it's looking for for standard universe. This should probably be fixed.
The CMakeLists.txt in question is the one in externals/bundles/glibc.
Patch the glibc external
The Debian 8 patches all worked except for disable-nscd.patch, which had an obvious fix.
Check the glibc external
The new configure script really wants the compiler to include flags. The solution to making CMake do this was simple but not immediately obvious (escape the space rather than quote part of the string).
Unlike the previous builds, the generated debian/include appears to be necessary. However, since it's constructed entirely out of symlinks into /usr/include (or empty files), I'm OK with keeping it around.
Build the Full Port
This was mostly just finding the GLIBC219 checks and adding GLIBC224 to them. One exception was wait4(); not sure if this is a glibc change or the compiler getting pickier, but apparently wait4()'s third argument really needs to be a pointer to int rather than a pointer to void. Updated the remap to match the new declaration.
Testing
The tests did not link. The first problem was that we had to explicit for everything in the standard universe, including the tests, that we were building static libraries (e.g., add -static to the flags everywhere).
The second was a problem with some symbols, including __libc_memalign, being multiply-defined. The last time this happened, the problem was user code calling memalign and causing it to link against the glibc versions in libcondor_c.a, rather than against the versions in libcondorsyscall.a. The problem was not in user code this time, and I wasn't able to isolate what else might have been calling it. Instead, I massaged malloc.o to make its symbols harder to link against (localized them) except for a few that were needed by libcondorsyscall.a that, as they were glibc-internal, should not have be necessary. It seems like maybe there's some premature linking going on in general with the new toolchain, but -fno-lto didn't seem to solve the problem. (Maybe something needs to be changed about the libraries are being built?)
The workaround resulted in a BaTLab test run with only two test failures. I haven't looked at the second one in any detail. The first one the first test's problem is as follows: unlike previous glibc implementations, version 2.24 does not have the *nocancel() family of functions; it instead has a set of #defines like the following:
#define __close_nocancel(fd) \ INLINE_SYSCALL (close, 1, fd)
which emits assembly which includes the syscall instruction. This means we can't intercept, for instance, the close() that you would expect to be called by fclose().
Work was paused there pending further demand.