wine-1.7.42 builds with gcc-5.1.0 without any issues, but fails at runtime:
err:process:start_wineboot failed to start wineboot, err 1359
err:winecfg:WinMain failed to restart 64-bit L"C:\\windows\\system32\\winecfg.exe", err 1359
Application tried to create a window, but no driver could be loaded.
The explorer process failed to start.
Apparently, this is a known problem.
> <slackner> tetromino: NP-Hardass: wine compiled with 5.1 is terribly broken
> <slackner> no need to test that, there are plenty of known issues
Upstream mailing list: http://thread.gmane.org/gmane.comp.emulators.wine.devel/100967
clang too? A separate error message would be slightly better if gcc is a hard requirement, IMHO. (I'm aware clang isn't officially supported in most of the tree.)
This is an optimization bug in GCC and is fixed upstream in
As a workaround I did:
CFLAGS="-march=native -O0 -pipe" USE="custom-cflags" emerge -va wine
With "-O0" optimization should be disabled.
Does not work without USE="custom-cflags"
Now winecfg works.
It is not fixed on the gcc-5 branch yet.
Will be fixed in gcc-5.2 (to be released in the comming days).
Created attachment 407042 [details]
With gcc-5.2 from the tree I get a different error with wine-9999.
I compiled this without the workaround.
(In reply to jospezial from comment #6)
> Created attachment 407042 [details]
> With gcc-5.2 from the tree I get a different error with wine-9999.
> I compiled this without the workaround.
Yes, there is another issue:
Unfortunately it only got fixed after the gcc-5.2 release.
I was holding off on getting toolchain involved until upstream's patches actually fix the issues. I've been interacting with wine devs, and thusfar, the patches upstream don't resolve the issues.
(In reply to NP-Hardass from comment #8)
ok, i was going by comment #7. feel free to redirect once all the issues shake out and there are patches for us to add to gcc.
I can confirm with this patch https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/gcc/postreload.c?view=patch&r1=225935&r2=225934&pathrev=225935 applied to gcc-5.2.0 wine compiles and runs successfully
Could gentoo include this gcc patch by default? Works for me, too. Thx.
Does somebody know about other packages hit by the second gcc bug?
Somehow 32bit wine-1.7.45 and wine-9999 doesn't segfault for me, whole system is built with gcc-5.2. Probably you should narrow down check in the ebuild.
(In reply to xpue from comment #13)
> Somehow 32bit wine-1.7.45 and wine-9999 doesn't segfault for me, whole
> system is built with gcc-5.2. Probably you should narrow down check in the
Interesting. Please attach your "emerge --info wine". Did you apply any patches to gcc?
Created attachment 409720 [details]
emerge --info wine
I only removed gcc5 check and added nine d3d9 patch.
I just started hitting this issue after upgrading some Wine dependency using gcc-5.2. This is with wine-1.7.41 compiled using gcc-4.9.2.
I'll take a look through the list of dependencies and see if I can determine which one broke it.
(In reply to xpue from comment #15)
> Created attachment 409720 [details]
> emerge --info wine
> I only removed gcc5 check and added nine d3d9 patch.
It seems that the runtime failure is happening with 64-bit wine. Probably we can remove the restriction when USE="abi_x86_32 -abi_x86_64".
The gcc-5 check is now applied only for 64-bit wine; 32-bit-only 1.7.50 seems to work fine with gcc-5.2.0.
(In reply to Alexandre Rostovtsev from comment #18)
> The gcc-5 check is now applied only for 64-bit wine; 32-bit-only 1.7.50
> seems to work fine with gcc-5.2.0.
I can confirm, that applying the patch mentioned in comment 10 to gcc-5.2.0 fixes the issue for 64bit wine on my machine.
winecfg works, and I just played a nice round of Mass Effect 1 on my laptop.
I have pushed an ebuild, app-emulation/wine-1.7.50-r1 to my overlay 'seden' (available via layman) which does no longer exit, but warns the user (with a 10 seconds delay) that said patch must be applied to gcc-5.2.0 before building wine.
Created attachment 410900 [details]
app-emulation/wine-1.7.50-r1 - ewarn instead of eerror and exit
The mentioned ebuild, for reference.
What about to add a recent gcc-5 snapshot to the tree and depend on that?
That would fix some other issues we do not know about.
The snapshots are announced at the gcc mailing list.
Let's ask toolchain to get this gcc patch into the tree.
adding this fix to gcc-5.2 shouldn't be an issue. we don't add snapshots to the main tree anymore.
Since this is a gcc bug and not a wine bug I'm removing it from the tracker.
should be fixed in current 5.2.0 version:
i can't push an updated ebuild as the git repo seems broken atm
(In reply to SpanKY from comment #26)
Thanks. But since there was no revision bump, how should the wine ebuild check for whether the currently installed =gcc-5.2.0 has the patch or not?
(In reply to Alexandre Rostovtsev from comment #27)
there will be a bump when it's unmasked
(In reply to SpanKY from comment #28)
> (In reply to Alexandre Rostovtsev from comment #27)
> there will be a bump when it's unmasked
For now, I've changed the gcc check in wine to simply run the PR66838 test case when gcc major version is 5 and minor is <= 2.