ld.bfd seems to be slowing down ppc64le ghc9.12 and ghc9.14 builds significantly. I tested on one of the fedora packager test machines (with 16GB) and the linking process for libHSghc-9.14.0.20251028-eebd_p-ghc9.14.0.20251028.so took over 2 hours! Similar timing happens in fedora koji (where the total build time is around 5 hours). Not sure if anything can be done to improve this, but I am considering to switch to lld which I think doesn't have this problem (local build took around 3 hours). If you test I suggest using ghc9.12 (since 9.14 seems to have some issue with ignoring LD perhaps). (Doesn't happen exactly for ghc9.10: likely because it doesn't provide dynamic prof libs.) Reproducible: Always Steps to Reproduce: 1. build ghc9.12 on Fedora ppc64le Actual Results: Build is stuck on ld for over 2 hours linking the main ghc library for profiling. Expected Results: Link should not take so long.
Hi Jens, I doubt if there is very much that can be done about this. ld.bfd was never designed to be fast, and I seriously doubt if it could ever catch up with any of the other linkers in terms of speed. Given that using LLD appears to be a sufficient workaround for you, I think that there is very little point in investigating this deeply. But just as a matter of interest, which version of Fedora are you using, and which version of the ld.bfd linker ? Cheers Nick
Thanks Nick I have been testing in a F43 vm and Rawhide (koji), so binutils 2.45 and 2.45.50. For Koji ppc64le, the time difference seems "only" 1 hour, so it seems to depend on the system. For x86_* and aarch64 there is no real difference in build times. So I just wondered why ppc64le seems particularly affected for this. (For builds without the profiling libs the difference also is small.) It seems this problem really started with the introduction of dynamic profiling libraries in 9.12 (before that there were only static profiling libraries). There are 824 objects in the library I think, so it is pretty big.