No subject

aarch64 support. Everything to date has been built against this glibc.
In the meantime, glibc 2.17 has been released upstream with aarch64 in
place. So at this point, it really makes sense to switch to 2.17 but
therein lies the problem. The upstream release has no compatibility
with 2.16 because 2.17 is the first release with aarch64 support. So
if one simply replaces the glibc binaries in the rootfs, nothing runs
because all of the other ELF binaries want to link against libraries
with glibc-2.16 version support.

We could get around this by just starting over from stage1 using the
new glibc. This wouldn't take as long as the first time because we have
already dealt with patches for failing packages. Even so, I think it
would take two or three weeks to get through all the builds since they
must be done serially in dependency order for the most part.

Not wanting to wait that long for a full rebuild, I looked at how to
work around the problem. I ended up with a small app which searches
through the existing ELF files and patches them so that they think
they were linked against 2.17 instead of 2.16. After a few false starts
I got it sorted out where the rootfs with patched binaries would boot
and I could replace the existing glibc libs with ones from a crossbuilt
2.17. Newly built binaries are now linked against 2.17 and we can avoid
the full rebuild. Of course, the binary RPMs we have built to date still
have binaries in them which require the 2.16 libraries, so they would
be unusable with glibc-2.17 in a mock chroot. I still haven't pushed the
patched ELF binaries to the git tree, so now would be a good time for
others to object to that ugly hackery or propose some other way of
working around the problem.

In the meantime, I am working on getting glibc-2.17 to build natively
from rpm. There are some issues there which will probably need some
patches to glibc itself and to the spec file. This is taking a lot of
time because of the build times on the sim. It makes restarting the
build painful, so I'm working through %install stage manually by
patching the specfile and using --short-circuit to avoid the %build
stage. I want to have something to use in a mock chroot ASAP and
leave proper patches for later once I have the full picture of what
is broken.

--Mark