last changes to ebuild (https://gitweb.gentoo.org/repo/gentoo.git/commit/app-emulation/wine-staging?id=20894379a00ea6f482884d4159217ce3b1bc21a2) is not adding -mno-avx unless flag "custom-cflags" is used. This is breaking many things (for example Battle.Net is crashing immediately). I would propose to have the change reverted and always add "append-cflags -mno-avx" until this is fixed in upstream or in some other way (compiler)
Have you misread it? It adds -mno-avx if USE="-custom-cflags" and allows USE="custom-cflags" users to pass -march=whatever still.
I understand that, but with custom-cflags until now we could use -march we wanted and the flag "-mno-avx" made sure that build of wine are working correctly there is no logical reason to have not "-mno-avx" not included if "custom-cflags" is used. The same reasoning for this could be the applied to lines: "filter-flags '-fstack-protector*' #870136 filter-flags '-mfunction-return=thunk*' #878849" don't apply them if "custome-cflags" is set
Per the commit message, this _particular_ bug isn't very well-understood and some people say it works fine for them without. USE=custom-cflags is precisely for this sort of situation. Those other two definitely break things.
OK, I have no problem to keep custom local repo with modified ebuild :) "custom-cflags" is there for custom cflags, but people don't know that there is a gcc bug that is causing problems. At least I would put a visible note to ebuild notifying them that "-mno-avx" was removed and they should add this to their CFLAGS if they experience crashes. For me winecfg is crashing, Battle.Net too. My CFLAGS: COMMON_FLAGS="-O2 -pipe -march=rocketlake -mabm --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=12288"
(In reply to Pavol Cvengros from comment #4) > OK, I have no problem to keep custom local repo with modified ebuild :) Ionen may feel differently than me. > "custom-cflags" is there for custom cflags, but people don't know that there > is a gcc bug that is causing problems. At least I would put a visible note > to ebuild notifying them that "-mno-avx" was removed and they should add > this to their CFLAGS if they experience crashes. > I'm just not sure why you're using USE=custom-cflags in the first place. strip-flags allows -march=native anyway. > For me winecfg is crashing, Battle.Net too. > My CFLAGS: > COMMON_FLAGS="-O2 -pipe -march=rocketlake -mabm > --param=l1-cache-line-size=64 --param=l1-cache-size=48 > --param=l2-cache-size=12288" I feel like what you really want here is for strip-flags to allow those through, as they're all reasonable? Which of those is it stripping out for you?
To be honest, I have never used or worked with "strip-flags". Without "custom-cflags" build the "build line" looks like: ============================================================== x86_64-pc-linux-gnu-gcc -m64 -c -o tools/wrc/wrc.o /var/tmp/portage/app-emulation/wine-staging-8.13-r3/work/wine-8.13/tools/wrc/wrc.c \ -Itools/wrc -I/var/tmp/portage/app-emulation/wine-staging-8.13-r3/work/wine-8.13/tools/wrc \ -Iinclude -I/var/tmp/portage/app-emulation/wine-staging-8.13-r3/work/wine-8.13/include \ -D__WINESRC__ -DNLSDIR="\"/usr/share/wine-staging-8.13/wine/nls\"" -DINCLUDEDIR="\"/usr/include/wine-staging-8.13\"" \ -DBIN_TO_NLSDIR=\"`tools/makedep -R /usr/lib/wine-staging-8.13/bin /usr/share/wine-staging-8.13/wine/nls`\" -DBIN_TO_INCLUDEDIR=\"`tools/makedep -R \ /usr/lib/wine-staging-8.13/bin /usr/include/wine-staging-8.13`\" -DWINE_UNIX_LIB -Wall -pipe -fcf-protection=none -fno-stack-protector \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self \ -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -O2 -pipe -march=rocketlake -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 ============================================================== so it will strip "-mabm --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=12288", those are not that super important so I will just try wothout them.
tl;dr I'm thinking to favor this side rather than those who really want their avx, so will revert soon'ish Problem was that I get people complaining the other way too (but I want to use avx! no issues for the things I run, or I patched it, or this doesn't happen if I use clang -target *-windows, or whatever) and generally the idea is that USE=custom-cflags is unsupported (as noted in the USE description) and just gives control back to users -- so things breaking when it's enabled is typically not considered Gentoo's problem. But guess I can agree that this comes as unexpected when it adds new flags rather than just strip flags that were potentially unsafe, e.g. maybe you have mostly safe flags as-is but really needed to stop one thing from getting stripped with USE=custom-cflags wrt the filters, fwiw these just straight up fail to build rather than give more undefined/questionable results -- not that I'd see a major problem with tossing them behind USE=custom-cflags too if someone asked
Btw. there is a big difference in using "-march=native" and "-march=rocketlake" at the moment. Right now with "native" Gentoo is no able to "rebuild" world as many many packages will just fail (I think including glibc) on Rocketlake cpus (and newer CPU).
pavol, can you file a separate bug for that last bit please? That sounds rather unexpected.
Thanks for all your replies. I will just adjust my builds.
(In reply to Sam James from comment #9) > pavol, can you file a separate bug for that last bit please? That sounds > rather unexpected. I will try to document it but I found the fix for my issues with build in Gentoo forums an bugtrack system. So I think it's already here. recommendation was to use "app-misc/resolve-march-native" to get proper/recommended CFLAGS for arch running
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44d2b75c2b8f8151d6d09e7dd2af4c6818e7b280 commit 44d2b75c2b8f8151d6d09e7dd2af4c6818e7b280 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-08-14 10:22:41 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-08-14 10:25:47 +0000 app-emulation/wine-proton: pass -mno-avx with mingw unconditionally Upon further consideration 84924628f0009acbe92b94ac28141c7ee322548e result in rather unexpected behavior even if we consider that USE=custom-cflags is unsupported, and giving a way to skip -mno-avx may not be all that worth it. So revert plus tidy and add this bugref. Closes: https://bugs.gentoo.org/912268 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/wine-proton/wine-proton-7.0.6.ebuild | 4 +++- app-emulation/wine-proton/wine-proton-8.0.3c.ebuild | 7 +++++-- app-emulation/wine-proton/wine-proton-8.0.9999.ebuild | 7 +++++-- 3 files changed, 13 insertions(+), 5 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=70b13c64ef94d1a6761b6d7324af66f3e38192c0 commit 70b13c64ef94d1a6761b6d7324af66f3e38192c0 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-08-14 10:22:24 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-08-14 10:25:46 +0000 app-emulation/wine-staging: pass -mno-avx with mingw unconditionally Upon further consideration 20894379a00ea6f482884d4159217ce3b1bc21a2 result in rather unexpected behavior even if we consider that USE=custom-cflags is unsupported, and giving a way to skip -mno-avx may not be all that worth it. So revert plus tidy and add this bugref. Closes: https://bugs.gentoo.org/912268 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/wine-staging/wine-staging-8.0.ebuild | 7 +++++-- app-emulation/wine-staging/wine-staging-8.11-r1.ebuild | 4 +++- app-emulation/wine-staging/wine-staging-8.12.ebuild | 4 +++- app-emulation/wine-staging/wine-staging-8.13.ebuild | 2 +- app-emulation/wine-staging/wine-staging-9999.ebuild | 2 +- 5 files changed, 13 insertions(+), 6 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d01071c8fd157a5d26cec16cd618a906e158cbad commit d01071c8fd157a5d26cec16cd618a906e158cbad Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-08-14 10:17:51 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-08-14 10:25:46 +0000 app-emulation/wine-vanilla: pass -mno-avx with mingw unconditionally Upon further consideration 9bef96cec566f1e06f5e9c40e52785b7b9702afa result in rather unexpected behavior even if we consider that USE=custom-cflags is unsupported, and giving a way to skip -mno-avx may not be all that worth it. So revert plus tidy and add this bugref. Closes: https://bugs.gentoo.org/912268 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/wine-vanilla/wine-vanilla-7.0.2.ebuild | 4 +++- app-emulation/wine-vanilla/wine-vanilla-8.0.1.ebuild | 7 +++++-- app-emulation/wine-vanilla/wine-vanilla-8.0.2.ebuild | 7 +++++-- app-emulation/wine-vanilla/wine-vanilla-8.11-r1.ebuild | 4 +++- app-emulation/wine-vanilla/wine-vanilla-8.12.ebuild | 4 +++- app-emulation/wine-vanilla/wine-vanilla-8.13.ebuild | 2 +- app-emulation/wine-vanilla/wine-vanilla-9999.ebuild | 2 +- 7 files changed, 21 insertions(+), 9 deletions(-)
