Summary: | Packages that use mingw-toolchain to build fail on 23.0 with /usr/lib/mingw64-toolchain/lib/gcc/x86_64-w64-mingw32/13/../../../../x86_64-w64-mingw32/bin/ld: unrecognized option '-z' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kyle Elbert <kcelbert> |
Component: | Current packages | Assignee: | Ionen Wolkens <ionen> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kcelbert |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
app-emulation/vkd3d-proton-2.12 build.log |
Description
Kyle Elbert
2024-03-28 09:11:58 UTC
Created attachment 888902 [details]
emerge --info
Created attachment 888903 [details]
app-emulation/vkd3d-proton-2.12 build.log
Note that this is self-inflicted, this is because of bashrc-mv adding ${LDFLAGS} to ${CFLAGS}, aka your: * CFLAGS='-march=native -ftree-vectorize -O3 -pipe -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -fstack-protector-strong -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs' -Wl,* options /don't/ belong in there -- and it is very silly. The ebuild normally removes it from LDFLAGS only thanks to strip-unsupported-flags but does not expect these to exist in CFLAGS. That aside, I can filter it anyway even if it makes no sense (I did for mingw64-toolchain, but thought it wouldn't matter for dxvk/vkd3d-proton because didn't think there'd be a combined line w/ meson). The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=18bba14d15e78f2572f74788d2557e095b91ddfb commit 18bba14d15e78f2572f74788d2557e095b91ddfb Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-03-28 10:05:56 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-03-28 10:10:06 +0000 app-emulation/dxvk: filter -Wl,-z,* ... for C(XX)FLAGS strip-unsupported-flags handles this fine in LDFLAGS, but -Wl,* are no-ops during compile-only tests (thus not stripped) and then if a package compiles and links anything at same time it fails. This used not to be a big problem but now that 23.0 profiles do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}" by default. Tempting to ignore it because of how wrong it is, but well. An alternate route could be to eventually have strip-flags and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS given this could affect more than mingw (e.g. switching to bfd when there is a lld-only option). wrt bug #928038, this already been done a while ago for wine, mingw64-runtime, and mingw64-toolchain itself and there *should* have been only dxvk and vkd3d-proton left (now done). Closes: https://bugs.gentoo.org/928038 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/dxvk/dxvk-1.10.3-r1.ebuild | 5 +++++ app-emulation/dxvk/dxvk-2.2-r1.ebuild | 5 +++++ app-emulation/dxvk/dxvk-2.3.1-r1.ebuild | 5 +++++ app-emulation/dxvk/dxvk-2.3.ebuild | 5 +++++ app-emulation/dxvk/dxvk-9999.ebuild | 5 +++++ 5 files changed, 25 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2c034d2d179a986b37b232221ac24cf64580fff6 commit 2c034d2d179a986b37b232221ac24cf64580fff6 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-03-28 10:05:01 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-03-28 10:10:06 +0000 app-emulation/vkd3d-proton: filter -Wl,-z,* ... for C(XX)FLAGS strip-unsupported-flags handles this fine in LDFLAGS, but -Wl,* are no-ops during compile-only tests (thus not stripped) and then if a package compiles and links anything at same time it fails. This used not to be a big problem but now that 23.0 profiles do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}" by default. Tempting to ignore it because of how wrong it is, but well. An alternate route could be to eventually have strip-flags and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS given this could affect more than mingw (e.g. switching to bfd when there is a lld-only option). Bug: https://bugs.gentoo.org/928038 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/vkd3d-proton/vkd3d-proton-2.10.ebuild | 5 +++++ app-emulation/vkd3d-proton/vkd3d-proton-2.11.1.ebuild | 5 +++++ app-emulation/vkd3d-proton/vkd3d-proton-2.12.ebuild | 5 +++++ app-emulation/vkd3d-proton/vkd3d-proton-2.6-r1.ebuild | 5 +++++ app-emulation/vkd3d-proton/vkd3d-proton-9999.ebuild | 5 +++++ 5 files changed, 25 insertions(+) Ew, that is pretty dumb of it to do. Probably going to end up writing my own portage bashrc section to do just the couple things I actually want. I already stopped using the LTO overlay that originally pulled it in ages ago. (In reply to Kyle Elbert from comment #5) > Ew, that is pretty dumb of it to do. Probably going to end up writing my own > portage bashrc section to do just the couple things I actually want. I > already stopped using the LTO overlay that originally pulled it in ages ago. fwiw it should have an option to disable this, NOLDADD does it I think? (not super familiar with bashrc-mv really) See: https://github.com/vaeth/portage-bashrc-mv/blob/main/bashrc.d/README Generally not a script I'm particularly fond of given it often caused issues similar to that (and users are not aware given it's default), sometimes because of CFLAGS in LDFLAGS too (other way around). (it supposedly does this to ensure flags are respected, however Gentoo had QA checks and automatic bug reports for flags not being respected for long time now) |