I've heads down lately building RPMs in stage3 and haven't posted any status in a while. I updated the wiki this morning with notes on the packages built so far: http://fedoraproject.org/wiki/Architectures/ARM/AArch64/Stage3Notes I think we now have everything in the rootfs which is needed to run mock itself. What we lack are packages to populate a repo which mock can use for it's chroot. We have built a lot of the necessary packages in stage3 but there is a problem with using those in the mock chroot. That problem is due to glibc. >From the start in stage1, we have been using glibc 2.16 patched with 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
