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
Debian 6 full port log
for more details. Note that for Debian 9,
apt-get source glibc
applied the patches;
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
, but still failed, unable to find
a long way into the build. Since
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
silliness. (Why bother if you're going to make symlinks?) This fixed the problem.
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
Patch the glibc external
The Debian 8 patches all worked except for
, 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
appears to be necessary. However, since it's constructed entirely out of symlinks into
(or empty files), I'm OK with keeping it around.
Build the Full Port
This was mostly just finding the
checks and adding
to them. One exception was
; 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
rather than a pointer to
. Updated the remap to match the new declaration.
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
to the flags everywhere).
The second was a problem with some symbols, including
, being multiply-defined. The last time this happened, the problem was user code calling
and causing it to link against the glibc versions in
, rather than against the versions in
. 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
to make its symbols harder to link against (localized them) except for a few that were needed by
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
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
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.