Description of problem: Recently I turned on debuginfo in ghcX.Y packages to avoid conflicts in /usr/lib.build-id symlinks. However with this I can now no longer build the package(s) locally. For example today when building ghc-9.4.1 locally (and the same for ghc-9.2.4) I get: + /usr/bin/find-debuginfo -j1 --strict-build-id -m -i --build-id-seed 9.4.1-8.fc37 --unique-debug-suffix -9.4.1-8.fc37.x86_64 --unique-debug-src-base ghc9.4-9.4.1-8.fc37.x86_64 --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /var/home/petersen/fedora/haskell/ghc9.4/BUILD/ghc-9.4.1 extracting debug info from /var/home/petersen/fedora/haskell/ghc9.4/BUILDROOT/ghc9.4-9.4.1-8.fc37.x86_64/usr/lib64/ghc-9.4.1/bin/ghc /usr/bin/debugedit: Cannot handle 8-byte build ID error: Bad exit status from /var/tmp/rpm-tmp.LoQgdh (%install) (This doesn't happen in Koji at least.) Version-Release number of selected component (if applicable): rpm-4.17.1-2.fc36 rpm-4.18.0-0.beta1
(This is a corresponding koji build scratch build (that fails for different reasons): https://koji.fedoraproject.org/koji/taskinfo?taskID=90603349 )
Thanks for reporting. Debugedit is maintained separately nowadays though, reassigning.
Hi, (In reply to Jens Petersen from comment #0) > + /usr/bin/find-debuginfo -j1 --strict-build-id -m -i --build-id-seed > 9.4.1-8.fc37 --unique-debug-suffix -9.4.1-8.fc37.x86_64 > --unique-debug-src-base ghc9.4-9.4.1-8.fc37.x86_64 --run-dwz > --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S > debugsourcefiles.list > /var/home/petersen/fedora/haskell/ghc9.4/BUILD/ghc-9.4.1 > extracting debug info from > /var/home/petersen/fedora/haskell/ghc9.4/BUILDROOT/ghc9.4-9.4.1-8.fc37. > x86_64/usr/lib64/ghc-9.4.1/bin/ghc > /usr/bin/debugedit: Cannot handle 8-byte build ID > error: Bad exit status from /var/tmp/rpm-tmp.LoQgdh (%install) The issue is the 8-byte build ID. 8 bytes is too small to generate a globally unique identifier. So ghc is producing these small build-ids. Maybe you are using the lld linker? It used to have a bug where it generated these small build-ids. Although I hope they have fixed that since.
(In reply to Mark Wielaard from comment #3) > The issue is the 8-byte build ID. > 8 bytes is too small to generate a globally unique identifier. > > So ghc is producing these small build-ids. (I can try asking upstream about it.) > Maybe you are using the lld linker? I think I am using ld.bfd (exclude on armv7hl). Should I try ld.gold perhaps? But I don't fully understand - this problem only happens for local builds not koji (mock?) builds. Are the build-id's generated differently there?
(In reply to Jens Petersen from comment #4) > (In reply to Mark Wielaard from comment #3) > > The issue is the 8-byte build ID. > > 8 bytes is too small to generate a globally unique identifier. > > > > So ghc is producing these small build-ids. > > (I can try asking upstream about it.) > > > Maybe you are using the lld linker? > > I think I am using ld.bfd (exclude on armv7hl). > Should I try ld.gold perhaps? No, ld.bfd is fine. Only the lld linker is known for generating these tiny build-ids (and I hope they fixed that some time ago). > But I don't fully understand - this problem only happens for local builds > not koji (mock?) builds. > Are the build-id's generated differently there? I know too little about how ghc generates its binaries. Usually the build-id is generated by the linker. Assuming ghc uses (a) standard linker it should just generate a proper build-id (unless it is buggy lld one). I don't know why ghc locally would use a different linker than the one used in koji. Maybe comparing a local build.log and a koji build.log would show a difference?
The only reference I could find so far is this function: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Driver/Pipeline/Execute.hs#L1181
Hmm that suggests that ghc is disabling build-id, though yet it works in Mock.
Moving this to ghc for now.
For my local build I get: $ objdump -j .note.gnu.build-id -s /home/petersen/fedora/haskell/ghc9.4/BUILDROOT/ghc9.4-9.4.1-9.fc38.x86_64/usr/lib64/ghc-9.4.1/bin/ghc /home/petersen/fedora/haskell/ghc9.4/BUILDROOT/ghc9.4-9.4.1-9.fc38.x86_64/usr/lib64/ghc-9.4.1/bin/ghc: file format elf64-x86-64 Contents of section .note.gnu.build-id: 2002e4 04000000 08000000 03000000 474e5500 ............GNU. 2002f4 2de52f1a a1d94e69 -./...Ni From a koji buildsystem build: $ objdump -j .note.gnu.build-id -s /usr/lib64/ghc-9.4.1/bin/ghc /usr/lib64/ghc-9.4.1/bin/ghc: file format elf64-x86-64 Contents of section .note.gnu.build-id: 4002e0 04000000 14000000 03000000 474e5500 ............GNU. 4002f0 636601b3 51792b07 1c70f924 fabf2d68 cf..Qy+..p.$..-h 400300 776d55c5 wmU.
$ /var/home/petersen/fedora/haskell/ghc9.4/BUILDROOT/ghc9.4-9.4.1-9.fc38.x86_64/usr/bin/ghc --info » 00:41:15 Wed 17日 » [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts","") ,("C compiler command","gcc") ,("C compiler flags","") ,("C++ compiler command","g++") ,("C++ compiler flags","") ,("C compiler link flags","-fuse-ld=gold") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","ld.gold") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("Merge objects command","ld.gold") ,("Merge objects flags","-r") ,("ar command","ar") ,("ar flags","q") ,("ar supports at file","YES") ,("ar supports -L","NO") ,("ranlib command","ranlib") ,("otool command","otool") ,("install_name_tool command","install_name_tool") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("unlit command","/usr/lib64/ghc-9.4.1/lib/bin/unlit") ,("cross compiling","NO") ,("target platform string","x86_64-unknown-linux") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target word big endian","NO") ,("target has GNU nonexec stack","YES") ,("target has .ident directive","YES") ,("target has subsections via symbols","NO") ,("target has RTS linker","YES") ,("target has libm","YES") ,("Unregisterised","NO") ,("LLVM target","x86_64-unknown-linux") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Use inplace MinGW toolchain","NO") ,("Use interpreter","YES") ,("Support SMP","YES") ,("RTS ways","debug thr thr_debug thr_p dyn debug_dyn thr_dyn thr_debug_dyn thr_debug_p debug_p") ,("Tables next to code","YES") ,("Leading underscore","NO") ,("Use LibFFI","NO") ,("RTS expects libdw","NO") ,("Project version","9.4.1") ,("Project Git commit id","6d01245c458c49ca25c89ec13be3268ab6930a27") ,("Project Version Int","904") ,("Project Patch Level","1") ,("Project Patch Level1","1") ,("Project Patch Level2","0") ,("Booter version","9.0.2") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","YES") ,("Target default backend","NCG") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Debug on","NO") ,("LibDir","/usr/lib64/ghc-9.4.1/lib") ,("Global Package DB","/usr/lib64/ghc-9.4.1/lib/package.conf.d") ]
Turned out your were right, Mark! ghc was preferring the lld that happned to be installed in my system, despite being configured to use ld.gold, shrug.