https://bugs.winehq.org/show_bug.cgi?id=54940
--- Comment #6 from Jacek Caban jacek@codeweavers.com --- (In reply to Zeb Figura from comment #5)
Huh? ld is still seeing active development;
Yes, it still exists and yes, it's still slow and memory hungry.
I'm probably getting unnecessarily annoyed, but for some reason it kind of irks me when someone does a hostile fork or reimplementation (with a harmfully permissive license, no less), then I hear claims that there's no reason to use the original project, regardless of the fact that it still exists and sees active development.
I never said there's no reason to use the original project. I think we should allow user to choose their preferred linker by supporting both of them. I believe that competition is good for users. We, as toolchain users, are in a better position having the choice than we'd be if we were stuck with a single provider, no matter which one.
My comment was about spending my own time on fixing ld.bfd itself, which is a very different thing than using it (and different than hacking Wine code to deal with its limitations). To elaborate more on that, for me the performance is a deal breaker when it comes to the linker of my first choice (although, since I generally contribute to mingw ecosystem, I have various configuration in my system and test things with all of them). When I ported wine-gecko to llvm-mingw, linking time went down from a few minutes to a few seconds and memory pressure was significantly reduced. When working on wine-gecko, this is a life quality improvement that's hard to negate and it's not realistic to completely fix as a side project. Even if other missing features in ld.bfd would be implemented (like delay load, PDBs or aarch64 support), it would still not be good enough for my own use case.
Others may have different priorities. Performance, for example, doesn't matter much when compiling Wine itself, because Wine builds relatively small executables. I'd be more than happy to see binutils being more competitive. That's why I wrote the comment, to give some feedback where to look at. To summarize, if someone is interested in working on it:
- If you just want to save a few seconds of Wine build time, fix dlltool. - If you additionally want to meaningfully improve binutils-based mingw toolchain, implement delay load in the linker. - In any case, it's not a Wine bug.
Also, I think that calling LLVM a hostile reimplementation is unfair. I guess you're referring to the fact that clang frontend is more-or-less compatible with gcc. I'd say that making porting between compilers easier is a good thing. Why would you intentionally make porting harder? Simplifying porting existing code base is a perfectly valid design choice in my opinion.
Especially when lld has some severe problems in terms of size and memory usage.
Huh, are you sure you not mixed linkers in that statement? Absurdly high memory usage is the reason I sometimes avoid using ld.bfd even on ELF target (where ld.bfd is my default distro linker otherwise, FWIW). I'm speaking from the actual experience, do you?