On Thu, Oct 20, 2022 at 09:42:58PM -0700, Steve Langasek wrote:
> This is good. One thing that I think has been missing from the discussion
> about armhf rebootstrap is the fact that we do have experience in Debian
> doing cross-cutting ABI transitions without having to change an
> architecture name. We've done this at least three times in Debian history:
> the libc5->libc6 transition ('g' suffix - which still remains today in
> libpam0g!), the GCC 4.0 C++ ABI transition ('c2' suffix), and the 'long
> double' transition ('ldbl' suffix, and an example of doing this for an ABI
> transition that didn't affect all architectures).> The first of these didn't require analysis, we knew all shared libraries > were affected (and Debian was much smaller then). > The second required analysis but it was easy because the C++ ABI is very > visible in ELF symbols. > The third is the best analogue to the time_t situation, because it involved > changing the size of a type that could appear not just in ABIs of C++ > libraries, but also C libraries. > And we did manage to survive that intact! > https://lists.debian.org/debian-devel/2007/05/msg01173.html > Nowadays, I wonder if abi-compliance-checker would be usable for analyzing > the ABIs of C libraries to accurately identify what needs to change for > time64_t. I think it would be interesting to know from this how many shared > libraries expose time_t size in their ABIs. Well, I didn't see anybody else expressing interest in this, so I had a go. I've done a first-pass analysis of Ubuntu lunar/armhf using abi-compliance-checker. The results of my investigation, including scripts and detailed reports/logs, are here: https://people.canonical.com/~vorlon/armhf-time_t/ Notes: - abi-compliance-checker was used to analyze headers of 767 library packages in the archive. Of those, 82 of 558 were successfully analyzed and identified as library packages that would need patched for the switch to 64-bit time_t to mark them as ABI-incompatible with the previous version on armhf. - an additional 209 packages could not be analyzed, because a-c-c failed to compile the headers using its invocation of gcc. Assuming a roughly equal distribution of ABI-changing vs non-ABI-changing libraries among these that have failed to compile, we'd be looking at around 113 of 767 libraries that need changed. - if we decide the level of effort to patch this many libraries is worthwhile, to get an actual actionable list of libraries that need patched for this transition would require getting the compile failures down to zero. I did dig into the failures alphabetically from "a" to "libe"; most of these failures were resolved by one of three methods. - letting a-c-c know that this is a C library and to not try to compile it with gcc's C++ frontend; - excluding various headers that can't be included directly, either because they are internal headers that are included via other headers in the package, or because they have dependencies on other headers not in the archive and can't be compiled (and therefore can't affect the library ABI); - pulling in additional undeclared package dependencies. Even when applying these fixes, I still had 8 library packages whose headers I wasn't able to get to compile. So there's still quite a bit of work to do here. - On this preliminary pass, I only included library packages that shipped both headers and .so's, as this supposedly gives the best quality results from a-c-c. To get a full list of ABI-breaking changes, however, we need to include packages that ship only headers and not .so's, to catch those libraries for which the .so is in a different binary package (boost), and to catch plugin systems for executables (apache). While I'm currently working on this using Ubuntu, the results are largely applicable to Debian, and the script itself certainly is. Note however that there are a couple of bugs in abi-compliance-checker that I've patched in Ubuntu, bug #951076 and bug #1030540, which you would want to have fixed before trying to run this analysis in Debian. Cc:ing the a-c-c maintainer for awareness of this. Does doing an ABI transition of ~113 libraries seem tractable to folks? If there's interest in moving forward on this, I'd say the next step should be to take it to debian-devel for broader discussion/signoff. I would also move my scripts into a git repository that folks can contribute to -- adding the necessary overrides for a-c-c for each library, so we can get an authoritative list of ABI breakages, is very parallelizable. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
