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

[Martin Storsjö]

On Fri, 22 Jan 2021, Jacek Caban wrote:

> On 22.01.2021 15:18, Martin Storsjö wrote:
>> On Fri, 22 Jan 2021, Jacek Caban wrote:
>> 
>>> Signed-off-by: Jacek Caban <jacek at codeweavers.com>
>>> ---
>>> FWIW, depending on distro, building in this mode may be as easy as adding 
>>> CROSSCC=clang to configure.
>> 
>> Regarding this, iirc it requires clang, lld-link and llvm-dlltool. The 
>> former two are easily available, but at least in ubuntu packages, the 
>> latter is only available in version-suffixed form as llvm-dlltool-7 or 
>> so.(I guess I should try to figure out whom to poke to get it available 
>> unsuffixed.) But maybe it's more available in other distros. 
>
>
> Yeah, it sounds like an Ubuntu bug, it's probably just missing a symlink.

I think, for some reason, they generally package all tools with a version 
number suffix (so they don't clash if you have multiple versions in 
parallel) and then have a userfriendly versionless symlink pointing at the 
latest installed one, or something like that. But they don't seem to add 
such symlinks for tools that aren't commonly used (e.g. they have a 
symlink for llvm-objdump, but not for llvm-readobj).

> 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.

// Martin