CTF state in binutils vs gcc

[Nix]

On 21 Aug 2026, Jan Beulich outgrape:

> Nick,
>
> when building released gcc versions, I prefer to build combined binutils+gcc
> trees. Doing so with 2.47 / 16.2.0, however, points out that include/ctf.h
> have diverged to a degree that it is not immediately obvious which header to
> take into the combined tree: 2.47's is newer than 16.2.0's, yet gcc won't
> build with binutils' header.

Ugh!

> Aren't the two files anyway supposed to remain in sync?

This is clearly something I'll have to look at when I make GCC speak
CTFv4 (probably after Cauldron, given that I'm still nailing down some
details of it in v3).

I'd expect them to be the same, but the codebase they serve is entirely
unrelated, so I'm not overly surprised they've drifted badly apart. In
general, binutils`s copy is the canonical one (it's the one that's meant
to be installed, the one that interoperates with ctf-api.h, which is of
course the public API header for libctf in binutils, etc).

I'll have a look at it. I suspect the right fix is to move include/ctf.h
in GCC into gcc/ and decouple things properly, but when I do CTFv4 I'll
try to make sure the same header works for both again.

-- 
NULL && (void)