Hi list,
Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901
Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c". The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib". Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode).
I'm not sure how to resolve it. Please advice.
Best regards, Andy
On Fri, Nov 13, 2020 at 02:16:46AM -0000, Andy Li wrote:
Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901
Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c". The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib". Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode).
I'm not sure how to resolve it. Please advice.
It means that the compiler identified a common compilation unit. A candidate for moving it to a dynamic library and making it a common dependency :)
Seriously we have seen this issue when projects bundled the same Wekbit. I don't remember what remedy was used. Maybe patching the code to differ enough to get a different build-id hash.
-- Petr
You could try adding this to one of the spec files
export LDFLAGS="%{?__global_ldflags} --build-id=md5"
Hi Andy,
On Fri, 2020-11-13 at 02:16 +0000, Andy Li wrote:
Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901
Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build- id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c". The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib". Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode).
I'm not sure how to resolve it. Please advice.
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?
Cheers,
Mark
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.
haxe's build log: https://kojipkgs.fedoraproject.org//packages/haxe/4.2.5/5.fc38/data/logs/x86... Relevant lines of building haxelib:
[ 50%] Building C object CMakeFiles/haxelib.dir/run.c.o /usr/bin/gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MT CMakeFiles/haxelib.dir/run.c.o -MF CMakeFiles/haxelib.dir/run.c.o.d -o CMakeFiles/haxelib.dir/run.c.o -c /builddir/build/BUILD/haxe-4.2.5/extra/haxelib_src/run.c /builddir/build/BUILD/haxe-4.2.5/extra/haxelib_src/run.c:105:13: warning: 'handle_signal' defined but not used [-Wunused-function] 105 | static void handle_signal( int signal ) { | ^~~~~~~~~~~~~ [ 75%] Linking C executable haxelib /usr/bin/cmake -E cmake_link_script CMakeFiles/haxelib.dir/link.txt --verbose=1 /usr/bin/gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -rdynamic CMakeFiles/haxelib.dir/run.c.o -o haxelib -lneko
nekovm's build log: https://kojipkgs.fedoraproject.org//packages/nekovm/2.3.0/11.fc38/data/logs/... The line of building libneko:
/usr/bin/gcc -fPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -shared -Wl,-soname,libneko.so.2 -o bin/libneko.so.2.3.0 CMakeFiles/libneko.dir/vm/alloc.c.o CMakeFiles/libneko.dir/vm/builtins.c.o CMakeFiles/libneko.dir/vm/callback.c.o CMakeFiles/libneko.dir/vm/elf.c.o CMakeFiles/libneko.dir/vm/interp.c.o CMakeFiles/libneko.dir/vm/load.c.o CMakeFiles/libneko.dir/vm/objtable.c.o CMakeFiles/libneko .dir/vm/others.c.o CMakeFiles/libneko.dir/vm/hash.c.o CMakeFiles/libneko.dir/vm/module.c.o CMakeFiles/libneko.dir/vm/jit_x86.c.o CMakeFiles/libneko.dir/vm/threads.c.o -lgc -ldl -lm
Did I miss some detail?
Best regards, Andy
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
-
Andy Li -
Leigh Scott -
Mark Wielaard -
Mark Wielaard -
Petr Pisar