As per the discussion at [1], our ABI checks would be more helpful if
we include a --headers-dir option in the abidw call, along the lines
of the attached patch. As things stand, changes in structs that
are intentionally abstract outside their defining module will
nonetheless be reported as ABI breaks, so that the tool completely
misses the point of the abstraction. But pointing it to the
installed headers tree alongside the binary seems to be enough to
fix that. I can confirm Andres' observation that the attached is
enough to change the currently-reported breakage to mention just
the globally-accessible struct.
Some notes:
1. It's kind of annoying not to fold this into the abidw_flags_list
option, but I don't see a good way to do that given that the headers
path is branch-dependent.
2. When installing this change into an active BF member, you'd better
blow away the abicheck.$animal cache tree, else you'll have a mess
from cached trees not having been analyzed with the same options.
(I experimented and indeed got some very strange ABI-diff complaints
when I hadn't done that.)
3. The same would likely apply to any change in abidw_flags_list.
Is it worth trying to automate that somehow, perhaps by recording
the flags used to build an abicheck cache file?
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/3256998.1769270320%40sss.pgh.pa.us#67ee3d4a9ebfc915dd6fa2cfecdcbedb
--- PGBuild/Modules/ABICompCheck.pm.save 2026-01-19 21:11:34.479973615 -0500
+++ PGBuild/Modules/ABICompCheck.pm 2026-01-24 12:21:26.524500885 -0500
@@ -842,7 +842,7 @@ sub _generate_abidw_xml
{
# Run abidw to extract ABI information into XML format
my $cmd =
- qq{abidw --out-file "$output_file" "$input_path" $abidw_flags_str};
+ qq{abidw --out-file "$output_file" "$input_path" --headers-dir "$install_dir/include" $abidw_flags_str};
my $log_file = "$log_dir/abidw-$target_name.log";
my $exit_status =
