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

Martin Storsjö martin at martin.st
Fri May 7 15:51:21 CDT 2021


On Fri, 7 May 2021, Jacek Caban wrote:

> On 1/22/21 8:34 PM, Martin Storsjö wrote:
>> On Fri, 22 Jan 2021, Jacek Caban wrote:
>> 
>> 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. 
>
>
> I revisited that after I found clang -print-prog-name and it seems to be 
> exactly what we need. I sent a patch that uses it to find LLVM tools. With 
> that, winebuild only needs to be able to find clang and leaves the rest for 
> clang.

Oh, nice! I didn't know about -print-prog-name, but that does indeed seem 
handy!

// Martin


More information about the wine-devel mailing list