[PATCH] winnt.h: Fix MSVC variants of InterlockedIncrement16 and InterlockedDecrement16.

[Jacek Caban]

On 24.01.2021 20:38, Jacek Caban wrote:
> On 22/01/2021 20:34, Martin Storsjö wrote:
>
>> On Fri, 22 Jan 2021, Jacek Caban wrote:
>>
>>> If there is reason for llvm-dlltool to be problematic, we may try to 
>>> use llvm-lib (or maybe even let lld-link do that for us).
>>
>> Not sure if there's a reason for it to be problematic, other than 
>> just not a very universally acknowledged tool in itself. (It only 
>> implements essentially 1 operation out of the ones that GNU dlltool 
>> support as well, generating import libs from def files, needed by the 
>> mingw-w64-crt build.)
>>
>> Reducing the tool interface down from 3 tools to 2 sounds pretty nice 
>> though, unless it's too much of a mess.
>
>
> It indeed sounds nice. I experimented a bit a got it working, I will 
> send patches after clean up and some testing. This way we may stop 
> requiring llvm-ar and llvm-ranlib as well.
>
>
> My first attempt didn't work because llvm-link does not support -def 
> option, which would allow creating a library from both object files 
> and def file in one pass. I got it working with two passes (which is 
> similar to how we handle other platforms anyway): first exec lld-link 
> -implib to generate importlib, then lld-link /lib to create a static 
> library. 


I had another look at it and I sent the part that replaces use of 
llvm-ar and llvm-ranlib with lld-link /lib. However, I couldn't get 
importlibs using lld-link -implib right. I tried MSVC, suspecting that 
something is wrong with lld-link, but I found that what I was trying to 
do is not supported by link.exe. -implib option is really meant for an 
addition to linker, not for importlib-only execution.


Unless I'm missing something, llvm-dlltool is currently the only 
supported way to do that using current LLVM. We could look at -def 
option support in llvm-lib, but a symlink in Ubuntu will be needed for now.


Thanks,

Jacek