Hi! On Tue, 2025-09-16 at 14:26:46 +0200, Guillem Jover wrote: > On Tue, 2025-09-16 at 13:39:53 +0200, Jérémy Lal wrote: > > Le mar. 16 sept. 2025 à 09:28, Guillem Jover <guil...@debian.org> a écrit : > > > I think using abigail for ABI tracking would be great, yes, but I don't > > > think it looks like a good fit for dependency tracking TBH. > > > > > > Its XML representation seems too detailed (which is needed for its ABI > > > tracking), which means you really need to build the package on each > > > architecture, then fetch the generated XML, add them to the packaging, > > > and upload again. And it looks like each XML file is going to be arch > > > specific (besides embedding the arch specific types, it will embed > > > multi-arch qualified header locations etc, unless there's a way to > > > track some kind of more generic template representation). > > > > Not sure about that, because of > > "abidiff uses by default, debug information in DWARF format" > > and I read that that format is architecture independent ? > > It has also some debuginfod integration. > > I don't see how this format can be architecture independent if it > needs to represent a detailed view of an ELF ABI, but perhaps what > is being referred to is that XML being a textual format it is > architecture independent in the sense that it can be parsed easily > on any system.
Err, sorry for my failure to read, you clearly were talking about the DWARF format. The problem is that it is still encoding information for an arch specific ABI, so its contents are going to be arch-specific, even if the format itself is arch-independent. > Attached the abidw output (default and an attempt to a somewhat minimal) > for libbsd0.so.0 for amd64 and i386, after installing libbsd0-dbgsym > and abigail-tools on two chroots. Running abidw as: > > ,--- > $ arch=$(dpkg-architecture -q DEB_HOST_ARCH) > $ multiarch=$(dpkg-architecture -q DEB_HOST_MULTIARCH) > $ abidw /usr/lib/$multiarch/libbsd.so.0 >libbsd-$arch.xml > $ abidw --no-load-undefined-interfaces --no-write-default-sizes \ > --no-architecture --no-corpus-path \ > --short-locs /usr/lib/$multiarch/libbsd.so.0 \ > >libbsd-$arch-minimal.xml > `--- > > As you can see for the default output for starters the files contain > an architecture name which will differ for each architecture, then > there will be the type sizes which will definitely differ between 32 > and 64-bit arches, and the header filenames I mentioned which will > differ for every arch, but there are going to be other differences as > well. (Other differences such as data alignment will affect type size, or how system structs are arranged per arch, or if they differ in members.) > The attempt at a minimal output while it removes some of the > above mentioned differences is still pretty much arch specific. Thanks, Guillem
