Arch Linux

I can confirm this:
https://bugs.winehq.org/show_bug.cgi?id=45276

See also here:
https://bugs.winehq.org/show_bug.cgi?id=45199#c22
This seems to fix the problem for me (resuling in only 5mb more installed wine):

diff --git a/repos/multilib-x86_64/PKGBUILD b/repos/multilib-x86_64/PKGBUILD
index 558ce97..31175f7 100644
--- a/repos/multilib-x86_64/PKGBUILD
+++ b/repos/multilib-x86_64/PKGBUILD
@@ -101,6 +101,9 @@ prepare() {
export CFLAGS="${CFLAGS/-fno-plt/}"
export LDFLAGS="${LDFLAGS/,-z,now/}"

+ export CFLAGS="${CFLAGS/-O2/-O1}"
+ export CXXFLAGS="${CXXFLAGS/-O2/-O1}"
+
patch -d $pkgname -Np1 < harmony-fix.diff

sed 's|OpenCL/opencl.h|CL/opencl.h|g' -i $pkgname/configure*

To fix it you just need to rebuild wine, wine-staging and wine-staging-nine with GCC 7.3.
https://bugs.winehq.org/show_bug.cgi?id=45199

I have what I *assume* is the same issue. Steam and some other applications crash during or shortly after being launched with wine.
There is a core dump collected by systemd for "services.exe". I have not confirmed what is happening on the wine level since I only today found out that wine has it's own debugging procedure.

I just want to report that I've tried all three of these reported workarounds and none of them have worked. Wine takes me about 30m to build so testing random suggestions is a bit slow.
In one build (I don't remember which one) applications still crashed but I didn't get the services.exe core dump.

export CFLAGS="${CFLAGS/-O2/-O1}"
export CXXFLAGS="${CXXFLAGS/-O2/-O1}"

export CFLAGS="${CFLAGS/-fno-PIC}"
export CXXFLAGS="${CXXFLAGS/-fno-PIC}"

export CC="/usr/bin/gcc-7"

If someone who understands the issue better has a better workaround suggestion it would be greatly appreciated.

@l4than-d3vers, I just made a downgrade to GCC 7.3 from Arch Linux package archive and this solved the problem.

https://wiki.archlinux.org/index.php/Arch_Linux_Archive

And I didn't used any of your e.v.'s:

export CFLAGS="${CFLAGS/-O2/-O1}"
export CXXFLAGS="${CXXFLAGS/-O2/-O1}"
export CFLAGS="${CFLAGS/-fno-PIC}"
export CXXFLAGS="${CXXFLAGS/-fno-PIC}"
export CC="/usr/bin/gcc-7"

Regards

Thanks for the response Kerr. Downgrading gcc and gcc-libs to 7.3 (and removing gcc7,gcc7-libs) did nothing. Same results. I already had gcc-8 before steam started crashing. I think I might be facing a different bug. I'll look into it more.

@l4than-d3vers, you should recompile Wine from source code using gcc 7.3 and gcc-libs 7.3.
It do nothing if you just install gcc 7.3 and gcc-libs 7.3 without re-build the Wine package.
Regards.

Yes that makes more sense. I just thought that building with CC="/usr/bin/gcc-7" should have had the same effect, but it didn't.
Seems to be working now. Thanks.

So, I hope that the Arch Linux maintainers will too recompile all of the Wine packages with GCC7.3 so long as we wait until Wine gets a real fix of this bug.
Regards.

Much likely also affected by this issue is running https://sourceforge.net/projects/grfloorboard/, see https://bugs.winehq.org/show_bug.cgi?id=45307.

Looking at https://bugs.winehq.org/show_bug.cgi?id=37540 , have you tried with:

export CFLAGS+=" -fno-PIC"
export CXXFLAGS+=" -fno-PIC"

@Paul Bredbury (brebs)
>Looking at https://bugs.winehq.org/show_bug.cgi?id=37540 , have you tried with:
>export CFLAGS+=" -fno-PIC"
>export CXXFLAGS+=" -fno-PIC"

No, I haven't, but this is absolutely related to this bug:
https://bugs.winehq.org/show_bug.cgi?id=45199

For a workaround, it's enough to build Wine using GCC 7.3, but I do not understand why Wine maintainers of Arch Linux does not do it, because that's why many applications/games fail to start/crash in Wine after compiling wine with gcc 8.1.0 and -O2 (GOT/PIC register load code now emitted at function entry, missing hotpatch signatures). Nothing prevents them from collecting Wine using GCC 7.3 for this until Wine upstream fixes this bug. This bug was opened 02 June 2018, but all new releases of Wine and Wine Staging are still compiled using GCC 8. Why is this happening?

GCC 7 is not needed. This fixes the crash at startup, in MS Office 2010:

unset CPPFLAGS
unset LDFLAGS
export CFLAGS="-march=x86-64 -mtune=generic -O1 -pipe"
export CXXFLAGS="-march=x86-64 -mtune=generic -O1 -pipe"

(Place these lines after the "export LDFLAGS=..." line in the PKGBUILD, obviously.)

I tested in wine-staging-pba 3.15-2 - https://aur.archlinux.org/packages/wine-staging-pba/

I expect that the changes can be narrowed down further ;)

@Paul Bredbury (brebs)
>GCC 7 is not needed. This fixes the crash at startup, in MS Office 2010:
unset CPPFLAGS
unset LDFLAGS
export CFLAGS="-march=x86-64 -mtune=generic -O1 -pipe"
export CXXFLAGS="-march=x86-64 -mtune=generic -O1 -pipe"
>(Place these lines after the "export LDFLAGS=..." line in the PKGBUILD, obviously.)

Thank you very much! I confirm that I've just checked your method and it really works for me!
Now it remains only to convince the Arch Linux Wine package maintainers to add this workaround to their PKGBUILDs.

This bug is now completely fixed for me by upstream. I believe that this bug report can now be closed. See here:

https://bugs.winehq.org/show_bug.cgi?id=45199#c44

To launch GR-55FloorBoard.exe I needed to downgrade wine-staging from 3.17-1 to 3.7-1 again.

Upstream closed for good the issue.
With 3.19 having been pulled in here minutes ago, we should do the same.

Neither a repository provides wine-staging > 3.18, nor upstream does, however, wine 3.19 from Multilib allows to open GR-55FloorBoard.exe.