A user reported this with mold in #gentoo while realising that their /usr/lib/wine-staging-7.15/bin was ~4GB, and I could also reproduce with lld on top: # ls -l /usr/lib/wine-staging-7.15/bin/wine{,64} -rwxr-xr-x 1 root root 2097158400 Aug 28 09:43 /usr/lib/wine-staging-7.15/bin/wine -rwxr-xr-x 1 root root 2097160144 Aug 28 09:43 /usr/lib/wine-staging-7.15/bin/wine64 To reproduce just need the following (USE doesn't matter afaik, was lld-14.0.6, and could reproduce with both gcc-12.2.0 and clang-14.0.6 -- don't think compiler matters): LDFLAGS="-Wl,-O1 -Wl,--as-needed -fuse-ld=lld" Don't know if the workaround has implications, but passing this to configure drops wine64 to ~8kB with lld and it still works: ac_cv_cflags__Wl___section_start__interp_0x7d000400=no That also only affects wineloader (wine/wine64 binary), doesn't touch libraries or anything else I can see. Not familiar with this, but guess(?) the start position is causing addition of empty padding or something like that. Also seems(?) harmless to pass for bfd too, so could probably be unconditional. Otherwise will need a tc-ld-is-bfd or tc-ld-is-mold which doesn't exist in toolchain-funcs.eclass currently. Alternatively there's tc-ld-force-bfd but that's probably overkill when there's a workaround. wine-vanilla most likely affected too, but haven't tested it (did get the same happen with Proton's wine-7.0-4 fork too, so I think it's all of them).
(In reply to Ionen Wolkens from comment #0) > Alternatively there's tc-ld-force-bfd but that's probably overkill > when there's a workaround. Or maybe not overkill? (optionally could be behind -custom-cflags, albeit doesn't fit the description) Tried runtime a bit more and I'm having rather mitigated success with lld either way (imagine same with mold), non-mingw builds seem entirely broken that I can see, and even with mingw there's still bugs like: https://bugs.winehq.org/show_bug.cgi?id=53402 (from Gentoo) wine-vanilla-7.0 and proton-7.0 also have broken x11 with lld, gets access violation while trying to load the winex11.drv then gives "err:winediag:nodrv_CreateWindow Unknown error" (wine-staging-7.15 seems better there) Not that I'm surprised with all these linker tricks.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a93609bbc6d8013ae7f10568a45db6589acc6005 commit a93609bbc6d8013ae7f10568a45db6589acc6005 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-09-09 17:37:48 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-09-10 09:47:15 +0000 app-emulation/wine-staging: add 7.17 using new ebuild See wine-vanilla-7.0-r3 commit for main list of changes, mostly same beside handling the patchset. For some notable staging-specific differences with original ebuilds: - no IUSE=staging, not planning to do merged ebuild logic currently - no IUSE=pipelight, not seeing a need to have a USE to disable this tiny patchset (seems was formerly treated specially given it was provided as unofficial patches in app-emulation/wine:0) - add IUSE=xattr fwiw, @system packages keep it optional too and disabling can have bit extra meaning for less multilib deps - use an array to pass patchinstall.sh options - add MY_WINE_STAGING_CONF for users to set their own exclusions - for live, now fetching the wine commit that current staging been based on by default (otherwise too volatile, users can still still use EGIT_OVERRIDE_* if wanted) Closes: https://bugs.gentoo.org/744829 Closes: https://bugs.gentoo.org/746338 Closes: https://bugs.gentoo.org/753698 Closes: https://bugs.gentoo.org/867097 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/wine-staging/Manifest | 2 + .../files/wine-staging-7.17-llvm-libunwind.patch | 9 + .../files/wine-staging-7.17-noexecstack.patch | 7 + .../wine-staging/wine-staging-7.17.ebuild | 350 +++++++++++++++++++++ 4 files changed, 368 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dda498c8aa4face18f47e637d1888f681f44ae6a commit dda498c8aa4face18f47e637d1888f681f44ae6a Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-09-10 04:17:12 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-09-10 09:47:14 +0000 app-emulation/wine-vanilla: add 7.17 using new ebuild See wine-vanilla-7.0-r3's commit for details Bug: https://bugs.gentoo.org/744829 Bug: https://bugs.gentoo.org/746338 Bug: https://bugs.gentoo.org/753698 Bug: https://bugs.gentoo.org/867097 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/wine-vanilla/Manifest | 1 + .../wine-vanilla/wine-vanilla-7.17.ebuild | 316 +++++++++++++++++++++ 2 files changed, 317 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f53d1bd478c460721be936f7691ba5744471edb6 commit f53d1bd478c460721be936f7691ba5744471edb6 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-09-09 14:37:37 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-09-10 09:47:14 +0000 app-emulation/wine-vanilla: use new ebuild for 7.0-r3 Based on wine-proton's rewritten ebuild with added logic to handle additional USE that are being forced in wine-proton but should be optional here. 7.17 to follow in a bump. Main goal is to make this hopefully easier to maintain and cleanup ancient constructs that haven't been relevant in 10+ years. Also fixes a few misc issues. List likely incomplete as haven't kept track of everything while writing wine-proton's ebuild, but for some notable differences compared to older ebuilds: - use upstream's way to handle multilib (--with-wine64) to ensure wow64 combined build is done as it should > like before it still allows 4 types, outline for clarity: amd64, abi_x86_32, abi_x86_64: full wow64, uses --with-wine64 amd64, -abi_x86_32, abi_x86_64: wine -> wine64, no --with-wine64 amd64, abi_x86_32, -abi_x86_64: default 32bit-only build, on 64bit x86, abi_x86_32, -abi_x86_64: default with nothing special - some other differences for ABI handling: > use /usr/lib/<variant> for both rather than lib64 > read CROSSCC_x86/CROSSCC_amd64 on top of wine's CROSSCC > CROSS flags check is done per-ABI rather than once for both > rely on MULTILIB_COMPAT to set REQUIRED_USE - force ld.bfd wrt bug #867097 and bug #744829, the various linker tricks currently make it unrealistic to use anything else and workarounds are insufficient for non-broken runtime even if it builds (note can still build with clang, it's lld/mold that lead to issues) - set QA_TEXTREL wrt bug #746338, seems expected given wine does these with -fno-PIC -Wl,-z,notext (aka don't treat DT_TEXTREL as errors) - fix execstack warnings for stub libraries (likely benign, just noisy) - handle stripping of PE files manually given portage doesn't know the right strip executable to use which resulted in warnings, potential mangling, and ignoring .exe/.dll files - use --<exact> for eselect-wine rather than --all to reduce noise - nonfatal eselect-wine for prerm, this allows removing wine in the event it was already deregistered notably if postinst's eselect-wine failed (which gives an error but doesn't fail installation) - do maintainer-oriented sanity check for matching mono on top of gecko's, check is always done regardless of USE and is only nonfatal for live version - various deps revisions, hopefully more pedantic, for some notes: > split dlopen'ed deps for clarity, these "could" be runtime optfeatures but realistically want wine to work as expected (split makes it easier to handle app-portage/iwdevtools' qa-vdb reports which gives a list of libraries it believes can be removed... and it turns out to be the dlopen list) > yacc -> bison, this explicitly looks for bison > XML-Simple -> XML-LibXML, it's what winemaker actually uses > move extras under X?, per configure.ac they are no-op if X is unset - IUSE newly enabled by default: > gstreamer: crippled without this and is only set by gnome profile > mingw: wine been focusing on PE conversions and most distros offer mingw builds making users hit unexpected issues if disabled (no longer need crossdev for this, so default is more reasonable now) > sdl: input devices like gamepads not being functional can be unexpected and unclear as to why (albeit desktop profile sets this) > vkd3d: matches later versions that have it always enabled as a bundled PE build > vulkan: grown in importance and matches already-default opengl - IUSE newly disabled by default: > perl: winemaker/dump are very rarely needed and may pull a chain of modules for no reason > udisks: unimportant for common usage and handled by desktop profile - IUSE added (disabled by default): > debug: to skip stripping of PE files, like other mingw packages > llvm-libunwind: use over libunwind - IUSE removed: > mp3: was a no-op forgotten IUSE > oss: this is ossv4 support which needs unpackaged media-sound/oss and a patched kernel, makes little sense to expose as USE that sometime confuse users (use EXTRA_ECONF=--with-oss instead) > realtime: wrt bug #753698, drop dependency on rtkit > run-exes: leave .desktop's MimeType alone (force current default), not convinced a USE to sed MimeType out makes sense and untrusted potentially harmful files are not limited to .exe, could be doing this for every .desktop (...don't open untrusted files, or use a user patch if really must) > threads: leave it up to defaults, no need to touch this (dos/samba optfeature'ish USE could make sense to remove but left alone for now) - no warnings if disable mono/gecko defaults, does not feel necessary - skip some unnecessary cruft, like > PATCHES_BIN code, unsure when this was last used > QA_DESKTOP_FILE, these are installed by wine-desktop-common > PLOCALES, wine been generating po/LINGUAS itself since wine-1.9.5 > xdg.eclass, updates are done by eselect-wine after putting files in a path xdg tools will recognize (meaningless in ebuild) > --enable-hal, like tons of --enable-* switches, it wasn't needed and only an issue because ebuild used to pass a hard --disable-hal > opencl 32bit check, virtual/opencl is different nowadays using a glvnd-like loader and it doesn't prevent building support even if there's ultimately no backend to load (not our job to check that), furthermore the test used eselect-opencl that is gone from the tree > env_vcs_vars: the eclass already inform of variables to use even in a multi-repo context (and -vanilla is not even multi) - not skipping l18n man pages + README based on LINGUAS (normally not used for this and is small files, use INSTALL_MASK if unwanted) - no multislot-apploader.patch, haven't found a way in which this matters with current layout and scripts seem to use the right slot - no multilib-portage.patch, need to support multilib-portage was already non-existent and got further dropped by a council vote - no winegcc.patch, unsure if was still relevant with current ebuilds but there is no known winegcc build issues with the new one - always run make_requests to handle patches rather than check md5sum, make_vulkan could make sense too but that requires adding python logic to the ebuild for something that's normally unneeded (make_requests is only optional for vanilla without user patches) - not using gentoo-wine-patches tarball, debatable but feel there's too few patches (and small) to be worth sharing across variants anymore (which may need rebasing anyway), and this skips the need to have per-developer URI logic/updates to maintain the tarball > also drop the hires icon it contained, questionable whether Gentoo should even handle this rather than use upstream's (ideally ping upstream's issue for attention instead, but could consider reinstating if it's really wanted) - use Wine's new gitlab, has more capabilities (e.g. shallow clones) - LICENSE update to include bundled libraries, e.g. libpng (not unbundled given PE files can't use system's ELF libraries) - copyright header reset to 2022-only, not based on old ebuilds Attempted to support tests (which previous ebuilds restricted), but concluded that skipping enough for a working subset would be too difficult to maintain, not to mention sandbox violations to fix and how easily it can hang. Bug: https://bugs.gentoo.org/744829 Bug: https://bugs.gentoo.org/746338 Bug: https://bugs.gentoo.org/753698 Bug: https://bugs.gentoo.org/867097 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../files/wine-vanilla-7.0-llvm-libunwind.patch | 9 + .../files/wine-vanilla-7.0-noexecstack.patch | 7 + .../wine-vanilla/wine-vanilla-7.0-r3.ebuild | 318 +++++++++++++++++++++ 3 files changed, 334 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=877936c3513d7ef069423a35a856a5ff7ba5c133 commit 877936c3513d7ef069423a35a856a5ff7ba5c133 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-08-11 09:48:23 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-08-11 10:33:54 +0000 app-emulation/wine-staging: tentatively allow lld again in latest Seems fine, no large binaries nor (obvious) issues at runtime. Please report if there's major issues that would require forcing bfd again. Mold still seems broken, no large binaries but been simply getting a Segmentation Fault when run winecfg. So do nothing if recognize bfd or lld, but force whichever is available otherwise. Leaving alone for older versions as a precaution. On a side-note, I hope nobody is passing -fuse-ld=lld in CFLAGS rather than LDFLAGS where it belongs as this would break compile+link at once mingw64-toolchain PE tests. Bug: https://bugs.gentoo.org/867097 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../wine-staging/wine-staging-8.13.ebuild | 23 ++++++++++++---------- .../wine-staging/wine-staging-9999.ebuild | 23 ++++++++++++---------- 2 files changed, 26 insertions(+), 20 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d53cd8f1e240085d7e6831caf5be0c076d28cd5 commit 3d53cd8f1e240085d7e6831caf5be0c076d28cd5 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-08-11 09:36:21 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-08-11 10:33:54 +0000 app-emulation/wine-vanilla: tentatively allow lld again in latest Seems fine, no large binaries nor (obvious) issues at runtime. Please report if there's major issues that would require forcing bfd again. Mold still seems broken, no large binaries but been simply getting a Segmentation Fault when run winecfg. So do nothing if recognize bfd or lld, but force whichever is available otherwise. Leaving alone for older versions as a precaution. On a side-note, I hope nobody is passing -fuse-ld=lld in CFLAGS rather than LDFLAGS where it belongs as this would break compile+link at once mingw64-toolchain PE tests. Bug: https://bugs.gentoo.org/867097 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../wine-vanilla/wine-vanilla-8.13.ebuild | 23 ++++++++++++---------- .../wine-vanilla/wine-vanilla-9999.ebuild | 23 ++++++++++++---------- 2 files changed, 26 insertions(+), 20 deletions(-)