<div dir="ltr">Hi,<div><br></div><div>lld-link already has an option to specify version. Please try to add "/version:14.0" to your command line.</div><div><br></div><div>As to whether we should set it to 14.0 (or some other version number) by default or not, we probably should. The reason why I didn't do that until now is just because I didn't see a need for that, but if a Microsoft tool expects some value there, there's no reason to not do that.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 1:25 AM, Simon Tatham via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello llvm-dev,<br>
<br>
I've recently been using clang-cl and lld-link to build Windows PE executables, which I then code-sign with Authenticode. I've found that although the resulting signed executables seem to validate successfully on Windows 10, they don't on Windows 7: right-clicking on one and bringing up the Windows Properties dialog shows either no 'Digital Signatures' tab at all (for a 32-bit binary), or one in which Windows says the signature doesn't validate.<br>
<br>
After some experimentation, it appears that this is a consequence of the 'linker version' field in the PE header being zero! lld-link sets both the MajorLinkerVersion and MinorLinkerVersion bytes to zero; Visual Studio's linker (as of VS2015) sets MajorLinkerVersion to 14. And if I patch lld to set MajorLinkerVersion to 14, the problem goes away, and my signed lld-linked executables validate just fine on Windows 7 as well as 10.<br>
<br>
I have no idea why this happens, though I speculate that if Windows is depending on the linker-version field at all then it's probably using it as a trigger to enable or disable particular bug workarounds (and making the unwarranted assumption that only one linker exists). But regardless of the reason, I think it would be more useful if lld-link wrote a value into that field that makes this use case do the right thing.<br>
<br>
Does that sound reasonable? If so, I'll prepare a patch. (Though I'm not sure whether I should do the trivial thing of just writing a value I know to work, or whether I should invent a command-line option to tell lld which version of Visual Studio's linker it should claim to be. The latter would be consistent with clang-cl's configurable compiler-version emulation, I suppose.)<br>
<br>
Cheers,<br>
Simon<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>