<div dir="ltr">Okay, I understand.  Thanks for your explanation :-)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tir. 26. nov. 2019 kl. 08.23 skrev Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The reason why we have different command line interfaces for different platforms is simply because they are actually different. It is not because lld is Windows-centric (it's not.)<br></div><div><br></div><div>The native linkers for these major platforms (e.g. link.exe or /usr/bin/ld) are quite different in terms of behavior. It's because native linkers have evolved separately in their environment for dozens of years. Each linker has evolved their own vocabulary (e.g. command line parameters) over the course of their history, sometimes borrowing concepts and command line flags from others, but they rarely made dead-copy features. Instead, they adjusted concepts to fit to their platform. So even if two command line options have the same or very similar names, they are not quite the same. So, if you create a unified command line interface, you'd likely end up with -unix-foo, -windows-foo, -mac-foo to support option -foo. You cannot merge them to option -foo by ignoring subtle differences.</div><div><br></div><div>WebAssembly is quite new, but they are pretty different from other binary formats because it is not a native binary format. For example, functions don't have addresses in wasm because they live outside of the wasm execution environment. As a result, even though wasm-ld borrows many options from Unix, it naturally has many wasm-specific command line options, and the options don't make sense for non-wasm targets.</div><div><br></div><div>The other problem of an imaginary unified driver is that it allows to use impossible combinations of features. Most command line options make sense for only one target, but if your linker accepts all options of all platforms, you would have to define some reasonable behaviors for all unprecedented combinations of features. That is actually a very difficult problem to solve. (Of course you can solve the issue by disallowing all combinations of command line flags of different targets, but that nullifies the point of creating a unified driver.)</div><div><br></div><div>So, yeah, it may look a bit silly to have different command line interfaces for all these targets, but I think it technically makes sense.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 26, 2019 at 2:49 PM Mikael Egevig via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I am using LLVM as the backend in a small hobby compiler project I'm working on.  I plan to support all platforms that LLVM supports (limited by my available hardware only).</div><div><br></div><div>As far as I can tell, there are different linkers for the various host systems out there (the output of 'lld' if you invoke it on Arch Linux): </div><div><br></div><div>    lld is a generic driver.<br>    Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld (WebAssembly) instead<br></div><div><br></div><div>I am wondering if there are any plans to make a single, standard, cross-platform link tool so that people who are not locked into the Microsoft ecosystem (Visual Studio and command-line tools) can use the LLVM linker without having to maintain three driver interfaces.  If I am not mistaken, you today have to use three or four different interfaces, depending on the host platform, just to link a few files.</div><div><br></div><div>The way I see it, a single LLVM-linker with the same options and syntax on all platforms would be highly beneficial to those who use LLVM as their backend through generating .ll files as input to the LLVM tool chain.</div><div><br></div><div>P.S. I am aware that I can use Clang as a gigantic driver for the linking process, but I am trying to get rid of all Clang dependencies because it is not needed by my project in any way.</div><div><br></div><div><br></div><div>Thank you,</div><div>Mikael Egevig</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>