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/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature