https://bugs.winehq.org/show_bug.cgi?id=52419
Bug ID: 52419 Summary: Wine 7.0 Release Doesn't Compile on Arch with GCC Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: nekoNexus@protonmail.ch Distribution: ---
Created attachment 71673 --> https://bugs.winehq.org/attachment.cgi?id=71673 Arch PKGBUILD File for Wine 7.0 Release
Using the default Arch makepkg flags (from /etc/makepkg.conf - by default this uses GCC), using this example PKGBUILD fails to link a few things in the 32-bit part of a WoW64 build thereby preventing compilation.
This also occurs if compiling with mingw is enabled, so that doesn't work either.
The error messages are all variations of: ". . . without base register can not be used when making a shared object"
https://bugs.winehq.org/show_bug.cgi?id=52419
nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #1 from Alexandre Julliard julliard@winehq.org --- Please attach a full build log.
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #2 from nekoNexus@protonmail.ch --- Created attachment 71675 --> https://bugs.winehq.org/attachment.cgi?id=71675 Build Log
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #3 from nekoNexus@protonmail.ch --- Performing this in a chroot makes no difference either.
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- https://bugzilla.redhat.com/show_bug.cgi?id=1573872 probably is related.
https://bugs.winehq.org/show_bug.cgi?id=52419
nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #71675|0 |1 is obsolete| |
--- Comment #5 from nekoNexus@protonmail.ch --- Created attachment 71676 --> https://bugs.winehq.org/attachment.cgi?id=71676 Re-done build log
The other system build log was attempting to use a gcc from another package I have (namely cuda); I removed it from the path for consistency so it should use the *actual* system compiler.
Issue still occurs though
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- Also running on arch, but it works just fine for me.
My makepkg.conf:
CARCH="x86_64" CHOST="x86_64-pc-linux-gnu" CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong" CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro" MAKEFLAGS="-j 12" DEBUG_CFLAGS="-g -fvar-tracking-assignments" DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
Yours?
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #7 from nekoNexus@protonmail.ch --- I reset the majority of these variables in the PKGBUILD, and I don't deviate that much from your own variables either, so I'm not sure what the issue is exactly? Maybe because I specified my CPU architecture specifically? (Which is still x86_64 based)
CARCH="znver2" CHOST="x86_86-pc-linux-gnu"
#-- Compiler and Linker Flags export CC=clang export CXX=clang++ export LD="/usr/bin/ld.lld" export AR="/usr/bin/llvm-ar" export NM="/usr/bin/llvm-nm" export AS="/usr/bin/llvm-as" export RANLIB="/usr/bin/llvm-ranlib" export STRIP="/usr/bin/llvm-strip" export OBJCOPY="/usr/bin/llvm-objcopy"
export OBJC=clang
#CPPFLAGS="" CFLAGS="-march=znver2 -mtune=znver2 -O3 -pipe -fno-plt -minline-all-stringops -fexceptions -Wall \ -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \ -fstack-clash-protection -fcf-protection" CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS" LDFLAGS="-Wl,-O3,--sort-common,--as-needed,-z,relro,-z,now" RUSTFLAGS="-C opt-level=3 -C target-cpu=native" #-- Make Flags: change this for DistCC/SMP systems MAKEFLAGS="-j$(($(nproc)+1))" #-- Debugging flags ## The "-fvar-tracking-assignments" flag is for GCC #DEBUG_CFLAGS="-g -fvar-tracking-assignments" DEBUG_CFLAGS="-g" #DEBUG_CXXFLAGS="-g -fvar-tracking-assignments" DEBUG_CXXFLAGS="-g" #DEBUG_RUSTFLAGS="-C debuginfo=2"
https://bugs.winehq.org/show_bug.cgi?id=52419
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- I thought this is about GCC, why have you set clang in there?
You could always try changing the flags to see what makes it work. Does it work with my flags?
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #9 from nekoNexus@protonmail.ch --- This is about GCC; I already stated that I *override* the global makepkg variables in the PKGBUILD file.
(I set the CC and CXX variables to GCC and the bash if-check in the file sets everything else as appropriate to what would normally be expected, CFLAGS aside.)
Check the attachment on this issue, it's in the zip file and is very easy to understand.
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #10 from nekoNexus@protonmail.ch --- I will try with your flags though; the majority of my flags *were* the Arch defaults back when I installed Arch (as far as I can remember), so I don't know if the defaults ever changed since then.
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #11 from nekoNexus@protonmail.ch --- Using your exact flags seems to build fine; I'm trying to identify now exactly what causes it to fail now.
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #12 from nekoNexus@protonmail.ch --- what caused it to fail* Sorry, I haven't eaten today and my grammar is suffering for it
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #13 from nekoNexus@protonmail.ch --- It seems the -fno-plt flag is the reason why this occurs
https://bugs.winehq.org/show_bug.cgi?id=52419
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #14 from Zebediah Figura z.figura12@gmail.com --- (In reply to nekoNexus from comment #13)
It seems the -fno-plt flag is the reason why this occurs
I don't believe we can support that flag, at least not on i386. We can't use GOT loads because some applications try to hook code by copying it and don't account for them (see e.g. [1]).
Is there a reason you need -fno-plt?
[1] https://source.winehq.org/git/wine.git/commitdiff/8f732c66ab37b54c30d63c74f7...
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #15 from nekoNexus@protonmail.ch --- No, I don't need it, but it's good to know that it shouldn't be used either way
https://bugs.winehq.org/show_bug.cgi?id=52419
--- Comment #16 from nekoNexus@protonmail.ch --- Might want to mention this in the compilation wiki
https://bugs.winehq.org/show_bug.cgi?id=52419
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Summary|Wine 7.0 Release Doesn't |Wine fails to compile with |Compile on Arch with GCC |-fno-plt Severity|critical |normal
--- Comment #17 from Zeb Figura z.figura12@gmail.com --- Clarifying title and resolving WONTFIX.
https://bugs.winehq.org/show_bug.cgi?id=52419
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Austin English austinenglish@gmail.com --- Closing.