Hi Andy,
(Please do put me on CC, I do try to read all of devel list, but it is easy to miss
something)
On Tue, May 02, 2023 at 11:42:30AM -0000, Andy Li wrote:
Sorry for the late reply. I just got back to this issue.
> In general this (should) only happen if the binaries are really
> identical (e.g. when one of the packages build requires the other, but
> instead of linking/rebuilding some sources it simply copies a binary
> directly).
>
> The build-id is (also) derived from the full nvra. So really cannot be
> identical even if the sources are. But this relies on the binaries
> being build with debuginfo. So maybe some code isn't build with -g?
I *think* both neko and haxelib were built with debuginfo, as I can find `-g` in the
logs.
Yes, that doesn't seem to be the issue.
The fetching the latest x86_64 packages
haxe-4.2.5-5.fc38.x86_64.rpm
nekovm-2.3.0-11.fc38.x86_64.rpm
you can see that the conflicting build-id is
/usr/lib/.build-id/b8/acf4f8271b78cd6dca636cb5b877c5c64f47f4
Which points to /usr/bin/haxelib in the first package
and to /usr/bin/neko in the second.
And if you compare them then they are indeed the same ELF file:
$ eu-elfcmp usr/bin/neko usr/bin/haxelib
$ echo $?
0
But they aren't really the same:
$ cmp usr/bin/neko usr/bin/haxelib
cmp: EOF on usr/bin/neko after byte 24632, in line 29
So after the ELF file data there is something else.
What I suspect is happening is that haxelib is really just a direct
copy of the neko binary with some bytecode added.
Cheers,
Mark