<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 10:36 AM, Saleem Abdulrasool <span dir="ltr"><<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Monday, August 17, 2015, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 16, 2015 at 1:43 AM, Saleem Abdulrasool <span dir="ltr"><<a>compnerd@compnerd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">compnerd added a comment.<br>
<br>
If we are fine with adding custom flags to the link command line, then aliases would be sufficient I think.  The idea is that you want to preserve the semantics of PE/COFF (which you called the semantics of Windows).  The difference is that the linker invocation should be similar to ld's, but continue to provide the current semantics.  There are a few extensions that are useful (which are compatible with the PE/COFF semantics), but the binaries that are generated by the alternate interface are meant to run on a Windows system, so losing the semantics of PE/COFF would be problematic.<br>
<br>
Just because the driver is written on/for unix, doesn't mean that the linker should provide unix semantics.  The semantics are that of PE/COFF because that is the target.  Its similar to how clang provides a GCC compatible interface which can still be used to generate a proper COFF object, even though ELF and COFF semantics are quite different.<br></blockquote><div><br></div><div>That's true, but in most use cases, Unix driver is used for Unix and provides Unix semantics, and so are COFF. Probably more than 99 out of 100 linker invocations, the default semantics are used. So defining a new driver layer for both Unix and Windows and then re-building the Unix and Windows drivers on top of it is too much. I really want something simpler.</div><div><br></div><div>There seems not necessary to create a new abstraction layer. We can write a small Python script or something which takes Unix ld-ish command line, translate that, and invokes lld-link with the translated options, can't we?</div></div></div></div></blockquote><div><br></div></div></div><div>As long as the script is part of the same repository, I see no difference.  It's just Python vs c++.  I'm not attached to any language, and we already need Python to build, so having that as a runtime dependency for llvm doesn't seem too big of a deal.  We should be able to document Python as a runtime dependency for lld I assume?<span></span> </div></blockquote><div><br></div><div>If I'm understanding this right, we would also need to add a dependency on a tool that converts python to .exe's. On unix, the file name of an executable doesn't matter and there is shebang. But on windows, you can't have a .exe program which is a python script without actually transforming it manually. So if a user wants to run the program without typing `python foo.py`, I believe that a py2exe-like solution will be needed. This would be an unfortunate dependency I think.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br><br>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org<br>
</font></span></blockquote></div><br></div></div>