https://bugs.winehq.org/show_bug.cgi?id=54940
--- Comment #7 from Zeb Figura z.figura12@gmail.com --- (In reply to Jacek Caban from comment #6)
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.
I'm sorry, I overreacted. I suppose I misinterpreted your statement about "little point in reimplementing [ld] when lld-link exists".
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.
My understanding was that LLVM is (was?) a hostile reimplementation of gcc specifically, not just a compatible replacement. However that's only based on hearsay and I can't even point to any specific statement.
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?
Yes. I remember at least one instance of LLVM specifically running out of memory with a large program when linking.
Also, while it's debatable whether it's related, LLVM has terrible problems with the size of its own binaries. It's something I notice whenever I need to debug out-of-memory conditions. libLLVM on this machine is an enormous 132 MiB, and if you count its nontrivial dependencies (including libxml2, libstdc++, libicudata/libicuuc) it's 187 MiB. (Compare libgccjit which is a mere 33 MiB (35 MiB with dependencies), less than a fifth of that. This doesn't inhere to a compiler; it's just that LLVM doesn't care about memory usage.)