[Bug 48161] New: AION (32bits) wine: Unhandled page fault on write access to 00000009 at address 00BF00C2 (thread 0009)
https://bugs.winehq.org/show_bug.cgi?id=48161
Bug ID: 48161 Summary: AION (32bits) wine: Unhandled page fault on write access to 00000009 at address 00BF00C2 (thread 0009) Product: Wine Version: 4.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: dracoanarion@gmail.com Distribution: ---
Created attachment 65789 --> https://bugs.winehq.org/attachment.cgi?id=65789 WINEDEBUG=+seh,+loaddll logs
The bug appears quite soon after starting the 32bit version of the app.
The app was started using the following command: /opt/wine-staging/bin/wine 'C:\AION\bin32\AION.bin' -ip:79.110.83.80 -noweb -noauthgg -st -charnamemenu -ingamebrowser -webshopevent:6 -f2p -lbox -litelauncher -64 -ncping -nosatab -aiontv -nobs -60f2p -n20 /SessKey: /CompanyID:11 /ChannelGroupIndex:-1 -lang:fra -litestep:9
This issue is not reproducible using wine-stable.
As far as I remember, this issue started to appear on 4.17 (but would need to be confirmed).
https://bugs.winehq.org/show_bug.cgi?id=48161
Fred dracoanarion@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://en.aion.gameforge.c | |om/website/download/
https://bugs.winehq.org/show_bug.cgi?id=48161
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #1 from Paul Gofman gofmanp@gmail.com --- Created attachment 65863 --> https://bugs.winehq.org/attachment.cgi?id=65863 partial proof of concept patch
It works for me with with the local build (default compiler options) and does not (with crashes similar to the one in this bug reports) with a prebuilt Wine binary I tested with.
The critical option in the prebuilt Wine is -fcf-protection flag. I could reproduce the crashes with it and avoid the crash by replacing 2-3 dlls compiled without the flag, otherwise the same.
-fcf-protection flag effectively results in adding endbr32 instructions to the code, in particular, at the beginning of each function. The game's anticheat seems to do a lot of trickery interpreting and rearranging API functions code. It doesn't understand endbr32 and that results in broken instructions execution. DECLSPEC_HOTPATCH (ms_hook_prologue) does not help here, as with it in place gcc still injects endbr32 right after hook prologue, and it still breaks things. I am attaching the patch as a proof of concept, which disables cf-protection for a few functions which are excluded from relay debugging. With this patch I could start the 32 bit game client with -fcf-protection build with WINEDEBUG=+relay. There are much more functions which the game wants to interpret, but relay thunks are good for it. Please note that using ms_hook_prologue instead of nocf_check doesn't help.
IMO the only solution is not to build Wine with -fcf-protection option. The option makes no sense anyway with Wine. Adding CET branch instrumentation does nothing by itself. In a CET-enabled environment indirect branching (jump, call, ret using some stored address) to any location not starting with enbdr will be denied. Out of CET environment endbr's are just no-ops.
If someone will try to run Wine with CET enabled it won't work anyway. ms_hook_prologue before endbr32 violates the CET requirement right away. I. e., "hot patchable" functions are simply incompatible with CET, or, in other words, ms_hook_prologue and cf_protection attributes are mutually exclusive. This is the most evident case, Wine use cases are probably incompatible with CET on deeper level. -fcf-protection added to Wine build is just adding no-op instructions which breaks some anti-cheats / DRMs.
https://bugs.winehq.org/show_bug.cgi?id=48161
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |z.figura12@gmail.com Resolution|--- |DUPLICATE
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- I think that makes this a duplicate of bug 48077, then. Thanks for debugging.
*** This bug has been marked as a duplicate of bug 48077 ***
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #3 from Paul Gofman gofmanp@gmail.com --- I don't know really if it is exactly duplicate or not: there are chances that UPlay can get away with DECLSPEC_HOTPATCH on some additional functions (like many other applications which do hotpatching) and thus be fixed regardless of this bug. Not sure if this is the case, I didn't try UPlay lately.
To put the issue here in the other words, I tend to think it is GCC bug. That is, I would expect gcc to issue an error if it encounters ms_hook_prologue when -fcf-option is used. Or issue a warning and make ms_hook_prologue do nothing when encountered. With -fcf-protection gcc is supposed to output a CET-enabled binary, which does not look possible with ms_hook_prologue on some functions.
https://bugs.winehq.org/show_bug.cgi?id=48161
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=48161
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|DUPLICATE |--- CC| |leslie_alistair@hotmail.com Status|RESOLVED |UNCONFIRMED
--- Comment #4 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Not a duplicate as DECLSPEC_HOTPATCH doesn't fix this issue.
https://bugs.winehq.org/show_bug.cgi?id=48161
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kevin.614@gmail.com
--- Comment #5 from Austin English austinenglish@gmail.com --- *** Bug 48231 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=48161
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com Summary|AION (32bits) wine: |AION (32bit) crashes (needs |Unhandled page fault on |-fcf-protection disabled) |write access to 00000009 at | |address 00BF00C2 (thread | |0009) |
https://bugs.winehq.org/show_bug.cgi?id=48161
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #6 from Austin English austinenglish@gmail.com --- https://source.winehq.org/patches/data/175129
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #7 from Zebediah Figura z.figura12@gmail.com --- *** Bug 48231 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #8 from Matteo Bruni matteo.mystral@gmail.com --- I imagine https://source.winehq.org/git/wine.git/commitdiff/cff35d4de1bbc7fb51a0f0317fbb138fdcf25f0d is a fix / workaround, can anyone confirm?
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #9 from Paul Gofman gofmanp@gmail.com --- I am not sure how exactly those different distributions builds are made, but if I add some additional flags using CFLAGS= variable for configure, those custom flags get added after the flags generated in configure script. So if -fcf-protection is there in CFLAGS= it will still take precedence.
Besides, unless I missed something, this change does not affect CROSS_CFLAGS, so mingw built libraries are unaffected by the change. I am afraid AION32 needs at least kernelbase.dll built without -fcf-protection, maybe something else.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Yes, CFLAGS take precedence. Don't add such flags in there.
I'm not aware of any mingw version that enables cf-protection by default, is there such a thing?
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #11 from Paul Gofman gofmanp@gmail.com --- (In reply to Alexandre Julliard from comment #10)
Yes, CFLAGS take precedence. Don't add such flags in there.
I don't do that for my own builds, but the official builds do add this flag somewhere.
I'm not aware of any mingw version that enables cf-protection by default, is there such a thing?
gcc does not enable this flag by default either. If Wine is built with default configure options (no messing with flags at all), it was already ok. The flag is added explicitly in official builds.
E. g., https://dl.winehq.org/wine-builds/fedora/30/x86_64/wine-devel64-4.21-1.1.x86...:
rpm -q --queryformat="%{NAME}: %{OPTFLAGS}\n" ./wine-devel64-4.21-1.1.x86_64.rpm:
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #12 from Paul Gofman gofmanp@gmail.com --- I rechecked now, and the endbr instructions are not there in mingw built binaries in official built, those added flags don't go to CROSS_CFLAGS of course. Sorry I messed that up a bit as I was building everything explicitly with -fcf-protection when was reproducing the bug / locating some of "bad" dlls / functions.
So there is no problem with mingw / crossflags. I am just not entirely sure where that -fcf-protection flag listed in rpminfo comes from in official builds. If it is put to EXTRA_CFLAGS, then I suppose it should be ok now.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #13 from Alexandre Julliard julliard@winehq.org --- (In reply to Paul Gofman from comment #11)
(In reply to Alexandre Julliard from comment #10)
Yes, CFLAGS take precedence. Don't add such flags in there.
I don't do that for my own builds, but the official builds do add this flag somewhere.
I'm not aware of any mingw version that enables cf-protection by default, is there such a thing?
gcc does not enable this flag by default either. If Wine is built with default configure options (no messing with flags at all), it was already ok. The flag is added explicitly in official builds.
No, it's apparently the default in Ubuntu 19.10, which is why it was broken there without any extra flags.
If some other packages add it to CFLAGS, then yes, these packages will have to be fixed.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #14 from Paul Gofman gofmanp@gmail.com --- The issue looks fixed in Ubuntu 5.0-rc1 binaries, but is still there in Fedora binaries:
objdump -t /opt/wine-devel/lib/wine/ntdll.dll.so
... 7bc91220 <NtQuerySystemInformation@@Base>: 7bc91220: f3 0f 1e fb endbr32 7bc91224: 8d 4c 24 04 lea 0x4(%esp),%ecx 7bc91228: 83 e4 f0 and $0xfffffff0,%esp 7bc9122b: ff 71 fc pushl -0x4(%ecx) ...
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #15 from Paul Gofman gofmanp@gmail.com --- Probably not directly related to this bug, but I tested the start of AION 32 bit with Ubuntu (eoan) binaries, and it crashes later during loading with:
*** stack smashing detected ***: <unknown> terminated
So the -fstack-protector which is also harmful and was addressed by https://source.winehq.org/git/wine.git/commit/684c272aa794757627ee0eee264a19... for default options somehow still gets into Ubuntu build.
https://bugs.winehq.org/show_bug.cgi?id=48161
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dimesio@earthlink.net, | |michael@fds-team.de, | |sebastian@fds-team.de Version|4.20 |unspecified Component|-unknown |wine-packages Product|Wine |Packaging
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- It's a packaging issue then.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #17 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Paul Gofman from comment #15)
Probably not directly related to this bug, but I tested the start of AION 32 bit with Ubuntu (eoan) binaries, and it crashes later during loading with:
*** stack smashing detected ***: <unknown> terminated
So the -fstack-protector which is also harmful and was addressed by https://source.winehq.org/git/wine.git/commit/ 684c272aa794757627ee0eee264a19fcd1052190 for default options somehow still gets into Ubuntu build.
What package did you see this in? The WineHQ 5.0-rc1 packages are all built with -fno-stack-protector and -fcf-protection=none.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #18 from Paul Gofman gofmanp@gmail.com ---
What package did you see this in? The WineHQ 5.0-rc1 packages are all built with -fno-stack-protector and -fcf-protection=none.
The snippet from Comment #14 is from https://dl.winehq.org/wine-builds/fedora/31/x86_64/wine-devel64-5.0.rc1-2.2....
The cf-protection is definately there. The objdump clearly shows the instructions at function start, and also:
rpm -q --queryformat="%{NAME}: %{OPTFLAGS}\n" ./wine-devel64-5.0.rc1-2.2.x86_64.rpm:
wine-devel64: -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
Regarding the Ubuntu binary, I've checked the disassembly and could not actually find stack protection code there. So the error I've got probably comes from some native libraries which were confused by something else. Unfortunately I don't have Ubuntu installation here at the moment and cannot test it properly, so the problem might be caused by my run of those binaries on Fedora, or, more likely, some completely different build specifics. Please note that AION32 still starts fine with my local build with default flags.
So what is exactly is wrong (if anything) with Ubuntu build is subject for further debugging, but frankly it would be much less time consuming for me if I could test an official Fedora build without -fcf-protection and stack protection first, and see if it is OK here, or if it shows the same problem, which I would debug on Fedora in this case.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #19 from Paul Gofman gofmanp@gmail.com --- (In reply to Paul Gofman from comment #18)
Regarding the Ubuntu binary, I've checked the disassembly and could not actually find stack protection code there.
I've now also checked a mingw build binary from Ubuntu build (https://dl.winehq.org/wine-builds/ubuntu/dists/eoan/main/binary-i386/wine-de..., kernelbase.dll), and some stack protection code is actually there (though it is not there in, e. g., ntdll.dll.so which is native gcc built):
712787d0 _PathUnExpandEnvStringsW@12: 712787d0: 55 push %ebp 712787d1: b8 ec 0f 00 00 mov $0xfec,%eax 712787d6: 57 push %edi 712787d7: 56 push %esi 712787d8: 53 push %ebx 712787d9: e8 32 b0 02 00 call 712a3810 <___chkstk_ms>
So maybe the problem that I see with Ubuntu binaries might have something to do with mingw built DLLs, though this could use more investigation of course.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #20 from Alexandre Julliard julliard@winehq.org --- __chkstk is a standard Win32 call for allocating large stack frames, it's not stack protection code.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #21 from Rosanne DiMesio dimesio@earthlink.net --- Created attachment 65998 --> https://bugs.winehq.org/attachment.cgi?id=65998 Fedora 31 5.0-rc1 build logs
Attaching i586 and x86_64 build logs from the Fedora 31 5.0-rc1 packages.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #22 from Rosanne DiMesio dimesio@earthlink.net --- I've attached the build logs from the Fedora 31 5.0-rc1 packages. FYI, build logs for all the WineHQ packages are publicly available on the OBS at https://build.opensuse.org/project/show/Emulators:Wine:Debian and https://build.opensuse.org/project/show/Emulators:Wine:Fedora.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #23 from Paul Gofman gofmanp@gmail.com --- (In reply to Rosanne DiMesio from comment #21)
Attaching i586 and x86_64 build logs from the Fedora 31 5.0-rc1 packages.
So those unwanted flags are actually there in the logs. This is before configure:
[ 203s] + CFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
And below in actual compiling too of course.
rpmbuild adds those distribution default flags, that should probably be addressed somehow in wine-devel.spec file, but I really never looked much into distribution build rules yet.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #24 from Paul Gofman gofmanp@gmail.com --- I've tested this with 5.0rc2 Winehq Fedora 31 and Ubuntu EOAN builds.
The issue looks solved with Fedora 31, AION 32 bit now starts normally with it.
There is still some problem with Ubuntu binaries. I get the following error in the terminal:
*** stack smashing detected ***: <unknown> terminated
Copying just ntdll.dll.so (32 bit) from Fedora 31 binaries solves the issue with Ubuntu binaries. My initial guess it might have something to do with these stack protection checks (using NtProtectVirtualMemory function just as an example):
7bcd8b00 <NtProtectVirtualMemory@@Base>: 7bcd8b00: 8b ff mov %edi,%edi 7bcd8b02: 55 push %ebp 7bcd8b03: 8b ec mov %esp,%ebp 7bcd8b05: 5d pop %ebp
...
7bcd8b37: 65 8b 0d 14 00 00 00 mov %gs:0x14,%ecx 7bcd8b3e: 89 4d e4 mov %ecx,-0x1c(%ebp) 7bcd8b41: 31 c9 xor %ecx,%ecx
...
7bcd8bd2: 74 24 je 7bcd8bf8 <NtProtectVirtualMemory@@Base+0xf8> 7bcd8bd4: 8b 45 e4 mov -0x1c(%ebp),%eax 7bcd8bd7: 65 33 05 14 00 00 00 xor %gs:0x14,%eax 7bcd8bde: 0f 85 a0 02 00 00 jne 7bcd8e84 <NtProtectVirtualMemory@@Base+0x384> ...
7bcd8e84: e8 fc ff ff ff call 7bcd8e85 <NtProtectVirtualMemory@@Base+0x385> 7bcd8e89: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi
...
These checks are absent in Fedora build which works fine.
I am not familiar with Ubuntu build specifics, and could not find the build logs by the link above (presumably I have missed something, but I could not see any logs among the downloadable files I found by the link). If I knew the complete list of build flags used I could guess which flag is responsible.
Strictly speaking, it is not the "fcf-protection" issue anymore and might be a separate bug as such, but it is still probably about incompatible build options.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #25 from Paul Gofman gofmanp@gmail.com --- FWIW I could reproduce the same crash when adding -fstack-protector or -fstack-protector-strong to the end of my local build flags for ntdll.dll.so. Looks like that specific check style as in the snippet in the previous comment appears with -fstack-protector-strong flag only, so probably this is the flag which somehow slips into Ubuntu build.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #26 from Zebediah Figura z.figura12@gmail.com --- Is it intentional that unauthenticated users aren't allowed to get debian.tar.xz files from e.g. [1]? Or is there another place they're supposed to be available?
[1] https://build.opensuse.org/package/show/Emulators:Wine:Debian/wine-devel
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #27 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Zebediah Figura from comment #26)
Is it intentional that unauthenticated users aren't allowed to get debian.tar.xz files from e.g. [1]? Or is there another place they're supposed to be available?
[1] https://build.opensuse.org/package/show/Emulators:Wine:Debian/wine-devel
To download it from that page, you have to be logged in. That's just how the OBS web interface works; it's not under my control. But anyone can create an account on the OBS, log in, and download the files. And anyone can view (and copy) the plain text files in their web browser without being logged in.
Alternatively, anyone can download the build files generated for a specific package from the download repository without being logged in, e.g., for Ubuntu 19.10, go to https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/xUbuntu_1....
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #28 from Zebediah Figura z.figura12@gmail.com --- Thanks, that works well enough.
Based on https://build.opensuse.org/public/build/Emulators:Wine:Debian/xUbuntu_19.10/i586/wine-devel/_log we're correctly passing -fno-stack-protector (and not passing -fstack-protector-strong), but the compiled binaries still have stack protection code touching %gs. Paul says it's baked into gcc. What can we do about this?
Note that the Debian builds still have -fstack-protector-strong appended, probably from the CFLAGS: https://build.opensuse.org/public/build/Emulators:Wine:Debian/Debian_10/i586/wine-devel/_log. Based on the ".diff.gz" files (which may be the wrong ones; I'm not familiar with Debian packaging), I see the line
+export DEB_CFLAGS_MAINT_STRIP = -fstack-protector-strong
present in the Ubuntu file but not the Debian one.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #29 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Zebediah Figura from comment #28)
Based on https://build.opensuse.org/public/build/Emulators:Wine:Debian/xUbuntu_19.10/ i586/wine-devel/_log we're correctly passing -fno-stack-protector (and not passing -fstack-protector-strong), but the compiled binaries still have stack protection code touching %gs. Paul says it's baked into gcc. What can we do about this?
If my current iteration isn't working (only in 19.10; see below), I don't have a clue. Suggestions are welcome, but note they need to be doable on the OBS, which is not a standard Debian build server.
Note that the Debian builds still have -fstack-protector-strong appended, probably from the CFLAGS: https://build.opensuse.org/public/build/Emulators:Wine:Debian/Debian_10/ i586/wine-devel/_log. Based on the ".diff.gz" files (which may be the wrong ones; I'm not familiar with Debian packaging), I see the line
+export DEB_CFLAGS_MAINT_STRIP = -fstack-protector-strong
present in the Ubuntu file but not the Debian one.
Originally I had one debian.tar.xz for all Debian/Ubuntu versions, which is how things are meant to work on the OBS. I had to create a separate one for Ubuntu 19.10 when I added -fcf-protection=none, because that caused build failures on some of the older distro versions. The DEB_CFLAGS_MAINT_STRIP line is currently only in the Ubuntu 19.10 rules file because that's where I've been testing attempts to try to strip out the default -fstack-protector-strong. My plan is to eventually add it to the rules file for other Debian/Ubuntu versions, but I need confirmation that it's actually working first.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #30 from Zebediah Figura z.figura12@gmail.com --- Whoops, I owe an apology; I checked the wrong package. The *Ubuntu* package seems to be correct, i.e. just from examining some previously affected functions, I don't see the stack protector being used. The *Debian* package is still affected, which aligns with the -fstack-protector-strong flag still being present in the build logs. So it would seem that the DEB_CFLAGS_MAINT_STRIP option is functioning as intended.
https://bugs.winehq.org/show_bug.cgi?id=48161
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #31 from Rosanne DiMesio dimesio@earthlink.net --- Beginning with 5.2, all our Debian and Ubuntu packages are built with
export DEB_CFLAGS_MAINT_STRIP = -fstack-protector-strong
so this should be fixed.
https://bugs.winehq.org/show_bug.cgi?id=48161
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #32 from Rosanne DiMesio dimesio@earthlink.net --- Closing fixed packaging bug.
https://bugs.winehq.org/show_bug.cgi?id=48161
--- Comment #33 from Zebediah Figura z.figura12@gmail.com --- Thanks!
-
WineHQ Bugzilla