Meson configuration of DXVK winelib build, with CC / CXX environment variables prepended, works for 64-bit build, but fails for 32-bit build. Without, the inverse happens.

[Valmar33]

Terminal output:

https://invent.kde.org/snippets/145

0009:err:process:replace_process 64-bit application L"Z:\\run\\media\\valmar\\Data\\Repositories\\Wine\\dxvk\\dxvk-mine\\build.32\\meson-private\\sanitycheckc.exe.so" not supported in 32-bit prefix
wine: Bad EXE format for Z:\run\media\valmar\Data\Repositories\Wine\dxvk\dxvk-mine\build.32\meson-private\sanitycheckc.exe.so.

meson.build:1:0: ERROR: Executables created by c compiler winegcc are not runnable.

Meson log for DXVK build.32

[nirbheek]

Sounds like this is further fallout from #5102.

[Valmar33]

Might be related, but it seems slightly different, being a little more severe.

At least it was possible to override the cross-compilation being ignored, and I recall being able to build it in the past, so this particular issue is caused by a newer commit.

I'll look into doing some bisection.

[Valmar33]

After a bit more thorough testing, I discovered that the 64-bit build fails without prepending CC=winegcc CXX=wineg++, but works with it.

Conversely, the 32-bit build works without prepending the variables, but not with it.

[Valmar33]

Curious bug.

[dhewg]

Sounds like #5102 to me.
It fails on 64bit because build=host and you work around it with CC=winegcc CXX=wineg++.
Workaround isn't required on 32bit because build!=host.

[Valmar33]

Ah, that makes sense now. Sounds like a complicated issue, from what I've been reading so far.

[Valmar33]

Should I close this, then?

[nirbheek]

Let's keep it open and we can verify that it's fixed.

[nirbheek]

Fixed with #5234 and verified.

[Valmar33]

This issue still persists for me, even with that pull request. :(

[nirbheek]

@Ericson2314 could you look at this too? Seems like it's not fixed by #5234

[dhewg]

@Valmar33: did you test the 0.50 branch? The fix is commited as fc0aad8 there, it's still broken on master

[Valmar33]

Yep, it works.

What are the plans for the master branch?

[Ericson2314]

#4010 would fix it better in my opinion.

[dhewg]

If #4010 is not close to being merged to master, it would be nice to commit fc0aad8 to master too. That wouldn't leave master in a known broken state. #4010 can then revert that temp fix and do it properly.

[Ericson2314]

@dhewg That's a fair plan. #4010 was ready but for a windows python failure I'm not sure how to debug (go to azure and rent some ssh?). Now there's that + creating another PR (which I'm doing today) to fix another regression better for master that should land first.

[aviau]

I have been getting this issue with meson 0.54.0. Is it still not fixed?

This breaks the DXVK build in Debian repositories.

Is there a patch that we could apply to Debian's meson in the meantime?

[Ericson2314]

I am sorry this has been such an issue, and wasn't just automatically fixed as I had hoped.

Is there a patch that we could apply to Debian's meson in the meantime?

The last "general env var cleanup" commit of mine you might try applying is #6827 . [I just rebased it so it will apply to 0.54 and master cleanly.] Do experiment with that, but I can't in good faith say just apply it Debian wide if it does help, as @jpakkane and I disagreed on whether the change is good and I don't want to circumvent his authority.

If that patch doesn't fix it---and at this point I am thinking that is likely----we'll need more details to get to the bottom of what's going wrong here.

[aviau]

Quick update: My build system does not allow for easy testing of your patch, but I intend to do this as soon as I have the time. Thank you for your quick response, I'll try to do my part in helping you debug this.

If the patch does not work, you can probably reproduce by getting a Debian machine and building dxvk in it. If you cannot access a Debian machine, please let me know and the Debian Project can give you remote access to one trough this process (I would sponsor the request).

I'll report back.

[Valmar33]

Please note that, at this point, it is very highly recommended to build DXVK with Mingw instead, as Winelib builds had all sorts of weird issues. Mingw is the officially-approved build method, also, I think.