Bug 928038 – 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'

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Kyle Elbert 2024-03-28 09:11:58 UTC]

so far (working through the emerge -e world from the profile change) both app-emulation/vkd3d-proton-2.12 and app-emulation/dxvk-2.3.1 have failed with this same error: 


FAILED: libs/d3d12/d3d12.dll 
x86_64-w64-mingw32-gcc -m32 -mfpmath=sse  -o libs/d3d12/d3d12.dll ../vkd3d-proton-2.12/libs/d3d12/d3d12.def libs/d3d12/d3d12.dll.p/main.c.obj -Wl,--allow-shlib-undefined -shared ../vkd3d-proton-2.12/libs/d3d12/d3d12.def -Wl,--start-grou
p -Wl,--out-implib=libs/d3d12/d3d12.dll.a -Wl,--kill-at -Wl,--enable-stdcall-fixup -Wl,--file-alignment=4096 -static -static-libgcc -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 -mno-avx -Wl,-O1 -Wl,--as-needed libs/vkd3d-common/libvkd3d_common.a -ldxgi -pthread -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid 
-lcomdlg32 -ladvapi32 -Wl,--end-group
/usr/lib/mingw64-toolchain/lib/gcc/x86_64-w64-mingw32/13/../../../../x86_64-w64-mingw32/bin/ld: unrecognized option '-z'
/usr/lib/mingw64-toolchain/lib/gcc/x86_64-w64-mingw32/13/../../../../x86_64-w64-mingw32/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status


Reproducible: Always




I'm running a custom profile that combines hardened with a 23.0 systemd plasma desktop, though the problematic ldflag was added to the base amd64 23.0 profiles : this is the parent file

gentoo:default/linux/amd64/23.0
gentoo:targets/desktop/plasma
gentoo:targets/systemd
gentoo:features/hardened/amd64

[Comment 1 Kyle Elbert 2024-03-28 09:13:14 UTC]

Created attachment 888902 [details]
emerge --info

[Comment 2 Kyle Elbert 2024-03-28 09:15:15 UTC]

Created attachment 888903 [details]
app-emulation/vkd3d-proton-2.12 build.log

[Comment 3 Ionen Wolkens 2024-03-28 09:57:56 UTC]

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).

[Comment 4 Larry the Git Cow 2024-03-28 10:10:57 UTC]

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 <[e-mail]>
AuthorDate: 2024-03-28 10:05:56 +0000
Commit:     Ionen Wolkens <[e-mail]>
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 <[e-mail]>

 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 <[e-mail]>
AuthorDate: 2024-03-28 10:05:01 +0000
Commit:     Ionen Wolkens <[e-mail]>
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 <[e-mail]>

 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(+)

[Comment 5 Kyle Elbert 2024-03-28 10:26:17 UTC]

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.

[Comment 6 Ionen Wolkens 2024-03-28 10:38:54 UTC]

(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).

[Comment 7 Ionen Wolkens 2024-03-28 10:40:19 UTC]

(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)