[patch] switch to xxhash for buildid recomputation

[Mark Wielaard]

Hi Frank,

On Tue, Oct 01, 2024 at 05:32:05PM -0400, Frank Ch. Eigler wrote:
> > [...]
> > > +# Checks for xxhash (mandatory, md5/sha1 buildid hashes are removed)
> > > +AC_CHECK_HEADERS([xxhash.h], [], AC_MSG_ERROR([missing xxhash.h]))
> > 
> > I think this configure check it not enough.  You also want to make
> > sure you have at least xxhash 0.8.0 by checking for XXH3 types or
> > functions (xxhash before 0.8.0 only supported 32/64bit hashes.
> 
> Replaced with a pkgconfig check.

OK, but why check for libxxhash >= 0.8.2?  Isn't >= 0.8.0 enough?  It
would exclude debian stable (0.8.1) and I would really like debuginfo
to build on that.

> > [...]
> > > +  /* Accept any build_id_size > 0.  Hashes will be truncated or padded
> > > +     to the incoming note size, as debugedit cannot change their
> > > +     size. */
> > > +  if (build_id_size <= 0)
> > >      {
> > >        error (1, 0, "Cannot handle %zu-byte build ID", build_id_size);
> > >      }
> > 
> > Do we really want to allow really small build_ids? We really need at
> > least 4 bytes, if they should be usable in the /usr/lib/.build-id
> > scheme. And at least 16 bytes (128 bits) to generate universially
> > unique build-ids.
> 
> They're silly small, but on the other hand, this is what the developer
> wanted with the incoming binaries.  debugedit per se can handle it and
> can leave policy to elsewhere.

Yes, debugedit can handle it now. But before it only handled 16 or 20
byte build-ids. So restricting it to 16+ bytes isn't a regression.
But I see your point, so lets keep it accepting silly small
build-ids.

I might introduce a sanity check in the find-debuginfo script though.

> OK, v2:

well... it is more like a diff against v1, except for the testcase?
Also it isn't easy to apply locally. Could you post something with git
send-email of git format-patch?

Thanks,

Mark