Dxvk: [winelib] Building dxvk like a native library?

[shmerl]

Proton changelog mentions:

DXVK is now built as a native Linux library, which may give a small performance boost, and should make debugging easier for DXVK and driver developers.

May be this should be added as an option to build and installation instructions?

[pchome]

1. Use corresponding cross-file
2. Done

[shmerl]

corresponding cross-file

Is it build-wine64.txt?

[pchome]

And build-wine32.txt, yes.

[shmerl]

Either way, adding it to explicit instructions would make it more clear. And how exactly is it installed / used in such case if it's not a dll?

[Guy1524]

@shmerl Proton probably has a custom way of installing it. DXVK's winetricks verb only works with the mingw build, so you'll have to put the dll.so in either your wine library folder, your prefix's system library folder, or your game's exe folder. Then set d3d11 and dxgi to builtin.

[shmerl]

OK, I'll give it a try. That's why instructions for this can be useful. May be another section on the Wiki. I can make something once I'll make it work.

[pchome]

Proton way:

env["WINEDLLPATH"] = lib64dir + "/wine:" + libdir + "/wine"

and

if "wined3d11" in config_opts:
    env["WINEDLLPATH"] = lib64dir + "/wine/wined3d:" + libdir + "/wine/wined3d:" + env["WINEDLLPATH"]
else:
    env["WINEDLLPATH"] = lib64dir + "/wine/dxvk:" + libdir + "/wine/dxvk:" + env["WINEDLLPATH"]

[shmerl]

So simply adding a path where those .so reside to WINEDLLPATH before launching something should work? Wine usually puts its own in lib/wine/fakedlls / lib64/wine/fakedlls.

[pchome]

https://github.com/doitsujin/dxvk/pull/607#issuecomment-417456171
I personally prefer hack+overrides.

For WINEDLLPATH to work you probably should split WINE built-in *.so the same way Proton does this.
For hack -- add all DXVK's d* libs to WINEDLLOVERRIDES and set them to either b - to use wine's libs, or n - to use DXVK's ones.

[doitsujin]

I don't advertize winelib builds for two reasons:

• It breaks wine's DLL override mechanism, so you can no longer force wined3d for specific applications by using WINEDLLOVERRIDES=d3d11,dxgi=b because it treats DXVK as the builtin option.
• The 32-bit winelib builds is even more prone to trigger out-of-memory errors than the mingw build is.
• I actually don't even know how to set it up in a non-hacky way (i.e. renaming d3d11.dll.so to d3d11.dll and putting it into the wine prefix).

[dhewg]

For the non-proton way see utils/setup_dxvk.sh.in, that's what it's for. It gets installed to your prefix/bindir.

It symlinks the dll.so files as dll in the system32/syswow64 folder and registers them:

~/.wine/drive_c/windows/system32/ ls -l|grep dxvk
d3d10_1.dll -> /home/andre/dxvk/lib64/d3d10_1.dll.so
d3d10core.dll -> /home/andre/dxvk/lib64/d3d10core.dll.so
d3d10.dll -> /home/andre/dxvk/lib64/d3d10.dll.so
d3d11.dll -> /home/andre/dxvk/lib64/d3d11.dll.so
dxgi.dll -> /home/andre/dxvk/lib64/dxgi.dll.so

Because of the symlinks you only need to do that once. They point to your prefix, so after rebuilding and reinstalling dxvk, wine will just use the fresh binaries.

[shmerl]

Ah, good to know that setup_dxvk.sh already handles that, I missed it since I've never tired building it that way yet.

[SveSop]

Hmm.. For starters (and newbs like me), you must also have these packages to do a "wine" cross-build.

g++-multilib
wine-devel-dev

Fine and dandy.. Builds oki, but for Ubuntu, the ninja install fubars something.. 32 vs 64 bit libs.
They are both installed in $PREFIX/lib/x86_64-linux-gnu. For Ubuntu it should have been $PREFIX/lib/x86_64-linux-gnu for 64 bit, and $PREFIX/lib/i386-linux-gnu if you follow whatever system standards. Any logic for 32/64 would be fine in my $PREFIX folder (eg. /home/myname/dxvk-release/lib32 or /lib64).

Easily remedied by doing ninja install and renaming the folder before doing the same for the next ARCH.

https://github.com/mesonbuild/meson/issues/1433 i was not able to figure out how to input the meson --libdir=lib anywhere, but it might/should be in the cross-file somehow?
https://github.com/mesonbuild/meson/issues/4008
Was easier than expected...

meson --cross-file build-wine64.txt --buildtype release --libdir=lib64 --prefix /home/myname/dxvk-release build.w64
meson --cross-file build-wine32.txt --buildtype release --libdir=lib32 --prefix /home/myname/dxvk-release build.w32

[SveSop]

Hacked together a "package-release-winelib.sh" script + "setup_dxvk_winelib.verb" (put in dxvk/utils folder).
Someone script-savy modify this so that "winelib" would be an build option? (combine the regular package_release.sh script with these mods...)
package-release-winelib.sh.gz
setup_dxvk_winelib.verb.gz

[pchome]

@SveSop

1. You can use any build-script you like to build DXVK
2. Add some logic to function build_verb, e.g.
   sed -e "s#DXVK_ROOT_DIR/x64#DXVK_ROOT_DIR/lib64#g" -i "$DXVK_BUILD_DIR/setup_dxvk.verb"
sed -e "s#DXVK_ROOT_DIR/x32#DXVK_ROOT_DIR/lib32#g" -i "$DXVK_BUILD_DIR/setup_dxvk.verb"
3. Also you can find some examples for winelib build here

[Sukid]

Just as a side note, you can also use Winelib builds in Lutris exactly the same way you do with the mingw builds Lutris automatically downloads. Just need to give it the same folder structure. So basically:
*Make a "Winelib" folder in /.local/share/lutris/runtime/dxvk/
*Make "x32" and "x64" folders in that.
*Copy the 32 and 64 bit versions of your winelib build respectively into each folder minus the setup_dxvk.sh and setup_dxvk_aur.verb.
*possibly copy setup_dxvk.sh into the /Winelib folder depending on how necessary that actually is.
*Type "Winelib" into the "dxvk version" field under the Runner Options tab for each game you want to use this with.

I'd recommend copying instead of symlinking because that might break Lutris' mechanism for loading DXVK.

I have noticed slightly better performance but I'm not sure if it's just an illusion from my own expectation of that or from using latest commits. I use the AUR package so I can't get a specific commit. That might prove worth testing...

[SpookySkeletons]

@Sukid You can append '#commit=HASH' to your AUR git source to grab a specific commit. Very interested in some benchmarks if you're up to it.

[SveSop]

@SpookySkeletons
I did a quick Unigine Valley + Heaven bench with winelib build. DXVK 0.90 + Wine-staging-3.18 w/stream patch.

Regular dxvk build: (Avg. fps (Score) min/max fps)

Valley:  101.3 (4239) 45.1/193.5
Heaven:   96.2 (2422) 33.9/183.1

Winelib build:

Valley:  102.2 (4277) 48.5/191.6
Heaven:   96.2 (2422) 35.1/182.9

Slightly higher fps in Valley, but both seemed to also have higher min fps but lower max fps.

Nothing revolutionary, but as i tend to think: 1 fps here, and 1 fps there...

Was not able to start World of Warcraft at all with the winelib build tho.. No errors from DXVK, but the "gx.log" in World of Warcraft/Logs folders complained that it could not find d3d11.dll. I used the "hack" method of symlinking /windows/system32/d3d11.dll (and the other dll's) to my dxvk/lib64/d3d11.dll.so file.

Hmm.. wonder if i should test renaming the *.dll.so files to *.dll and copying them into the /system32/ and /syswow64/ folders directly? Heaven/Valley/Superposition worked with the "symlink dll hack" tho.. (Superposition being 64 bit same as wow.exe).

[SveSop]

Nah. Copying the dll files directly to their respective system32 / syswow64 folders as *.dll did not work either. Not sure how to troubleshoot this, as it kinda seems to be a wow bug in that it dont think d3d11.dll is valid enough to load? Wine seems happy, dxvk seems happy.. wow.exe does not.

GxDeviceD3d11::ILoadD3dLib(): unable to LoadLibrary("d3d11.dll")
gx.log.gz

Some compile flag to test perhaps?

[doitsujin]

Do you have d3d11.dll set to native? If so, remove the override as winelib builds are treated as builtin.

[pchome]

To be clear: winelib builds are treated as both builtin and native. So other then disabled values don't meter.

Only using patched loader renamed *.dll.so files are forced to respect builtin value.

[SveSop]

@doitsujin Removing all overrides caused:

wine: Call from 0x7bc769d8 to unimplemented function dxgi.dll.DXGID3D10CreateDevice, aborting
0x80000100 (unknown exception) at 000000007bc769d8 : error 132: ERROR #132 (0x85100084) Fatal exception!

Valley worked no matter if they were set to native , builtin or not set at all just like @pchome sais.

Kind of weird it would be a difference for wow.exe and not for valley.exe. Perhaps some weird dependency in the wineprefix that was set up long ago? It's absolutely most likely some sort of misconfiguration on my part tho...

[SveSop]

So.. is winelib build any different from regular dxvk when building? Ie. I would still need system32/dll's pointing to the lib64/dll.so's? And syswow64 -> lib32/dll.so? Or is something different in that way? Just wondering since i seemed to have to pass the --libdir= option (se a few posts up) so the compiles were not all dumped in the same folder overwriting eachother... Not sure how proton solves this tidbit when creating 32 and 64 bit libs?

file dxgi.dll.so
32-bit:
dxgi.dll.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=8ac1189cb6bc9d3638166c7c1258bd42d059f0e4, stripped
64-bit:
dxgi.dll.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=d1997ca1266e39a6666a1b46eea33c2214e0fc88, stripped

That looks kinda identical to the wine's own 32(lib) and 64(lib64) dll's... (xept for the BuildID's ofc)

[pchome]

@SveSop

wine: Call from 0x7bc769d8 to unimplemented function dxgi.dll.DXGID3D10CreateDevice, aborting

It looks like you compiled it wrong, both WINE and DXVK should have this declared. But compiler can remove (optimize out ?) some code if you messed with dependencies.

And to be sure: you should rename *.dll.so to *.dll after compilation, or use symlinking ln -s /build/dxgi.dll.so /use/dxgi.dll ...

[SveSop]

@pchome Yeah, i actually ended up using
cp "$DXVK_BUILD_DIR/install.$1/x$1/d3d10.dll.so" "$DXVK_BUILD_DIR/x$1/d3d10.dll" in my script, so that the output from the build would be name-wise exactly as the regular dxvk build.

However.. One thing i DO notice is that my x86_64-w64-mingw32-gcc --version output is:
x86_64-w64-mingw32-gcc (GCC) 7.3-posix 20180312
but winegcc is:
gcc (Ubuntu 8.2.0-1ubuntu2~18.04) 8.2.0

So.. could gcc-8.2 do something weird vs. mingw-7.3? Hmm... Guess i could try swapping gcc to the release 7.3 build?

[SveSop]

Tested building with gcc/g++ -7 (7.3), but that did not change anything.

The errormessage listed in WoW's gx.log lists:
GxDeviceD3d11::ILoadD3dLib(): unable to LoadLibrary("d3d11.dll")

Googling this "LoadLibrary" error, i found this:

To use glibc, you don't need to make changes to your application; it should work straight away. There are a few situations in which using glibc is not possible:

Your application uses Win32 and C library unicode functions.
Your application uses MS specific calls like beginthread(), loadlibrary(), etc.
You rely on the precise semantics of the calls, for example, returning -1 rather than non-zero. More likely, your application will rely on calls like fopen() taking a Window s path rather than a Unix one.

In these cases you should use msvcrt to provide your C runtime calls.

https://wiki.winehq.org/Winelib_User's_Guide

So, could there be something iffy going on with Wow.exe using this loadlibrary() function, and compiling dxvk as a winelib breaks this?
I tried to compile with the mentioned -mno-cygwin flag, but that produced only errors when compiling.

[SveSop]

Oh well... That was certainly funny.
This is what i had to do to make World of Warcraft work with winelib build:

1. Copy the winelib dxvk *.dll.so files -> wine-staging-3.18/lib64/wine (64bit) and wine-staging-3.18/lib/wine (32bit) (replacing the winecompiled *.dll.so's directly)
2. Symlink dxvk's *.dll.so -> *.dll in the respective system32(64bit) and syswow64(32bit)
3. Remove all dll overrides for my wineprefix.

Oh.. and it does not work in a "pure" 64bit wine setup, even tho this works fine with mingw compiled dxvk and a wine-staging-3.18 compiled only as 64 bit.

Now.. All this was NO problem for Unigine (valley/heaven/superposition).. I suspect World of Warcraft does some strange loading (LoadLibrary) function that either looks at some filepath/filename/whatever a winelib does not support. Dunno...

Tried to remove symlinks - crash. Tried to set dll overrides to "builtin" - crash. Do not copy the *.dll.so into wine folder, replacing the wine compiled *.dll.so's - fail.

[SveSop]

Or tbh, my dxvk compile (ubuntu 18.04) uses a weird/wrong header file someplace... Probably the most likely scenario?

[ssorgatem]

In my AUR packages ( https://aur.archlinux.org/pkgbase/dxvk-wine-git/ ) I have a winetricks verb that sets up winelib DXVK with symlinks.

[shmerl]

Just built dxvk as .so, and used dxvk_install.sh for The Witcher 3. It worked fine. However I don't see any major difference with .dll build. If anything, .dll actually produces 1 fps more seemingly (in the same location).

[SveSop]

Fiddled a wee bit more with this, but same problem with World of Warcraft.

Built the dll.so files, and just overwrite the wine-staging dll.so's, and remove all dll overrides. No symlinks. In theory that would work just as it would be wine's own dll.so's right?

And as previous, it does for Unigine Valley (32-bit), and Unigine SuperPosition (64-bit).

Using the same custom wine for my World of Warcraft prefix (no overrides, and no symlinks) does produce this GxDeviceD3d11::ILoadD3dLib(): unable to LoadLibrary("d3d11.dll") error.

Reading a bit on https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/ it seems to be something that has LoadLibrary function. Does this mean it is something that needs to be included in the dxvk-version of d3d11/dxgi for WoW to kinda "use" this function? Would that not be a function included in wine regardless of the d3d11 version running? Or is it something that WoW tries to call "through" the DirectX api currently running?

include/Makefile.in:333:    libloaderapi.h \
include/winbase.h:40:#include <libloaderapi.h>

is in my wine-tree...

[shmerl]

FYI: Debian now provides packaged native (winelib) variant of dxvk: https://tracker.debian.org/pkg/dxvk

[SveSop]

Thanks @shmerl

Does not fix the problem i have with loadlibrary and World of Warcraft... So does not seem as its a compiling error on my part then.

Down to 2 options i guess:

1. Something on my setup/wineprefix that makes this happen. Perhaps i should recreate my prefix unless someone else with WoW can test this.
2. World of Warcraft uses this "loadlibrary" function to load d3d11.dll into some memory space, and with wine/wine-staging's fake dll's and/or regular wined3d dll.so's this works, while dxvk does not have this "function" and something goes tits up. Using dll-redirects obviously seem to "fool" the system, or it also may be that mingw-w64 automagically adds this somehow?

Searching for "World of Warcraft" and "LoadLibrary" comes up with some references to WoW private servers and/or cheats... and ways to bypass WoW's "Warden" (their anti-cheat mechanism). So, it MAY be that the WoW client uses this function to check/keep tabs on various dll's.. and by using wine dll.so's that does not support this "feature", this goes tits up. Dunno.. theory tho :) (Since winelib works with several other games).

[SveSop]

Some light reading? Dunno if its relevant tbh...
https://github.com/NVIDIA/winex_lgpl/blob/master/winex/documentation/HOWTO-winelib

Maybe wine dll.so's do a "loadlibrary" on the fake dll's, but when dxvk symlinks are used, the dll's are "real" (ie. Native dll-redirect) vs. dxvk winelib dont do/support this with the fake dll's, so a windows app actually trying to load the fake dll (through the dll.so) just falls short as the actual file is just "crud" (since the log file points to d3d11.dll) :)

Nuff rambling from me tonight :)

[SveSop]

Taking a look at fake-dll's, it seems as they have some binary implementation of various "functions" to "fool" windows to use something like that...

Doing a "cat" on the standard wine included fake-dll d3d11.dll, it seems to contain "features" that are listed in the d3d11.spec file (wine-source). So, maybe a new fake-dll could be produced from the dxvk d3d11.spec (and other .dll's) and that could solve some weirdness with the loadlibrary function?

I am not able to create a proper fake dll tho.. Tried to use winebuild -m64 --dll --fake-module -o d3d11.dll -E dlls/d3d11/d3d11.spec in the wine source folder did not create anything near the proper fake wine created d3d11.dll. So i must be doing something wrong :)

Maybe @pchome have any hints for me?

[SveSop]

After a lot of trial and errors.. and googling.. and IRC tips, i figured out a way to compile a fake_dll that seemingly had the data from dxvk's .spec files atleast :)

Did not help for WoW's "loadlibrary" problems tho.. so i guess im back at square1 there.

Needed to use wine-staging to get useful data for some reason.. so i might still just be fumbling in the dark here, but this is what i did:
winegcc -o d3d11.dll.fake -BPATH_TO_WINE_STAGING/bin/ -m64 -fasynchronous-unwind-tables -shared PATH_TO_DXVK_SOURCE/src/d3d11/d3d11.spec
(replace "PATH_TO..." with your respective cusom paths ofc)

One interesting tidbit was that i had to end the -out file with .fake. If i just renamed it directly, it would be just a "plain" fake-dll with no real data in it.

PS. Needless to say: Repeat for d3d10.spec and so on + make 32-bit ones with -m32

[pchome]

Maybe @pchome have any hints for me?

Like "Use winetricks dxvk90 for this prefix"?

After a lot of trial and errors.. and googling..

I have no idea what you trying to do, but it seems you currently reverse-engineering man winegcc, man winebuild, WINE loader and WINE build logs.

For "proper" fakedll you need to pass the same data as for .so, in other words:

• winegcc -o d3d11.dll.so ... flags includes sources will generate d3d11.dll.so
• winegcc -o d3d11.dll.fake ... flags includes sources will generate fakedll.

Also, I have no WoW installed to test, and have never faced such errors (I'm using winelib builds almost always).

P.S.: You can try to use WINEDEBUG="+timestamp,+pid,+tid,+seh,+debugstr,+module" to get more detailed output for a loaded modules.
P.P.S.: I don't get it -- why you trying to create fakedlls, when you need to rename *.dll.so->*.dll to use winelib build.

[SveSop]

I thought i had explained this somewhat in the previous posts...

There is a issue with World of Warcraft, where using "winelib" does not work. Not as renamed dll.so´s (symlinks and whatnot) and not as a "true" winelib build, where you actually replace wine´s native dll.so. It either crashes or get a error with "loadlibrary".

Having to use symlinks + copy the wine dll.so´s seem to be a weird "need" for WoW tbh, but if this has to do with some copy protection thing, it MAY be interesting for other games in the future? Or steam-games with some particular sort of copy protect?

I dont know if the "make a more correct fake-dll" is of any use. Might be that dxvk needs some includes to "support loadlibrary"? (winapi.h?) Dunno..

[leonmaxx]

@SveSop
Just a guess, try adding DllMain function:

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    return TRUE;
}

[SveSop]

Still experimenting a bit with this tbh, but since I dont have any programming experience other than trial & error, and some googling.. i found something that could be interesting in the winegcc manual:

-mno-cygwin
Use Wine's implementation of MSVCRT, instead of linking against
the host system's libc. This is necessary for the vast majority
of Win32 applications, as they typically depend on various features
of MSVCRT. This switch is also used by the MinGW compiler to link
against MSVCRT on Windows, instead of linking against Cygwin's
libc. Sharing the syntax with MinGW makes it very easy to write
Makefiles that work under Wine, MinGW+MSYS, or MinGW+Cygwin.

Trying to compile with option -mno-cygwin results in loads of stuff failing (naturally i guess). Then i tried adding this option to dxvk_extradep in meson.build, and compiled without error, but now wow throws a

ACCESS_VIOLATION : error 132: ERROR #132 (0x85100084) Fatal exception!
 The instruction at "0x00007efd2200c5a1" referenced memory at "0x0000000000000001".
The memory could not be "read".

when starting..

Instead of GxDeviceD3d11::ILoadD3dLib(): unable to LoadLibrary("d3d11.dll"), it turns into a access_violation when fiddling with that -mno-cygwin option.

The winelib users guide also mentions this:

To use glibc, you don't need to make changes to your application; it should work straight away. There are a few situations in which using glibc is not possible:

Your application uses Win32 and C library unicode functions.
Your application uses MS specific calls like beginthread(), loadlibrary(), etc.
You rely on the precise semantics of the calls, for example, returning -1 rather than non-zero. More likely, your application will rely on calls like fopen() taking a Windows path rather than a Unix one.

In these cases you should use msvcrt to provide your C runtime calls.

Add -mno-cygwin to your compiler flags. This will cause winebuild to resolve your C library calls to msvcrt.dll.

In fairness, if i have not missunderstood something, building a winelib dll.so is supposed to be used as a native wine dll.so, and replacing the d3d11.dll.so (and dxgi+++) files in my custom wine compile DOES work without setting any overrides or creating symlinks for tests i did with Unigine benchmarks. DXVK is enabled and running, but doing the same for WoW does NOT work.

I am pretty sure this is due to SOME sort of weird call WoW does when "opening" d3d11.dll, and possibly does not find some library that is/should be included?

Doing a ldd on the default wined3d d3d11.dll.so

linux-vdso.so.1 (0x00007ffc56f77000)
libwine.so.1 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7108363000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7108754000)

Doing ldd on winelib compiled dxvk d3d11.dll.so

linux-vdso.so.1 (0x00007ffd3ff6a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fef79cbd000)
libwine.so.1 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fef79934000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fef79596000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fef791a5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fef78f8d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fef79eea000)

Probably due to being compiled as g++ rather than gcc that wine uses?
Does wineg++ use linux libc "msvcrt" functions the wine msvcrt.dll.so does not have, and fails on something?

[leonmaxx]

@SveSop Try static linking for libstdc++ - compiler flag -static-libstdc++.
Also you can try:
-static-libgcc - statically link gcc runtime
-static - statically link everything what is possible.

[SveSop]

Thx for the suggestion, but

Static linking is not currently supported against Wine's DLL. As a
result, the -static, --static, and -Wl,-static options will generate
an error.

I did not get an error trying out -static-libstdc++ , but it dit not help either :)

PS. But might not be doing this right.. Tried both for the cpp_args, and the dxvk_extradep.
And i can see its used when linking when using ninja -v in the buildscript.

[mati865]

@SveSop WineHQ packages are unpacked to /opt, try adding /opt/wine-staging/lib64/ to your LD_LIBRARY_PATH. If running your own Wine build point to it instead.

[SveSop]

Did not really make a difference @mati865
Why would the winegcc manual mention the reason to use -mno-cygwin if it was not needed? And why would the mingw-w64 build use "-static, static-libgcc and static-libstdc++" if it was not needed by a winelib build?
It does not SEEM to be "needed", as eg. Unigine benchmarks work with the winelib build... And most likely lots of other stuff (if not everything else but WoW for all i know).

mingw-w64 does not support that flag at all, cos its "obsolete", so i dunno if its just some winegcc thing thats not really being updated?

[2/189] wineg++ -m64 --no-gnu-unique -mno-cygwin -Isrc/util/util@sta -Isrc/util -I../../Temp/dxvk/src/util -I../../Temp/dxvk/./incl$
FAILED: src/util/util@sta/sha1_sha1_util.cpp.o
wineg++ -m64 --no-gnu-unique -mno-cygwin -Isrc/util/util@sta -Isrc/util -I../../Temp/dxvk/src/util -I../../Temp/dxvk/./include -fdi$
In file included from /usr/include/c++/8/cwchar:44,
                 from /usr/include/c++/8/bits/postypes.h:40,
                 from /usr/include/c++/8/bits/char_traits.h:40,
                 from /usr/include/c++/8/string:40,
                 from /usr/include/c++/8/stdexcept:39,
                 from /usr/include/c++/8/array:39,
                 from ../../Temp/dxvk/src/util/sha1/sha1_util.h:3,
                 from ../../Temp/dxvk/src/util/sha1/sha1_util.cpp:2:
/opt/wine-devel/include/wine/msvcrt/wchar.h: In function ‘wchar_t* wmemcpy(wchar_t*, const wchar_t*, size_t)’:
/opt/wine-devel/include/wine/msvcrt/wchar.h:501:18: error: invalid conversion from ‘void*’ to ‘wchar_t*’ [-fpermissive]
     return memcpy(dst, src, n * sizeof(wchar_t));
            ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/wine-devel/include/wine/msvcrt/wchar.h: In function ‘wchar_t* wmemmove(wchar_t*, const wchar_t*, size_t)’:
/opt/wine-devel/include/wine/msvcrt/wchar.h:506:19: error: invalid conversion from ‘void*’ to ‘wchar_t*’ [-fpermissive]
     return memmove(dst, src, n * sizeof(wchar_t));

Using this flag with dxvk and winegcc seems to bug out on non-available functions in wine's msvcrt implementation, and ref. to the above winegcc manual COULD result in something not working when the "systems" msvcrt is used?

[shmerl]

Moved Elex performance report with winelib to bug #805.