https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-emulation/dxvk-1.10.1 fails to compile (lto). Discovered on: amd64 (internal ref: lto_tinderbox) NOTE: This machine uses lto with CFLAGS=-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Created attachment 787874 [details] build.log build log and emerge --info
It's either not possible to use LTO here or it'll need extensive work to make wire up the plugin for the cross bit.
Works if it can just find a symlink at: /usr/lib/mingw64-toolchain/x86_64-w64-mingw32/lib/bfd-plugins/liblto_plugin.so Unsure if a cleaner way to handle, but given this is a all-in-one gcc-only package, I think there's no real concerns doing that.
My worry was about stuff like bug 751295 but if it works, why not?
Indeed, tried full slew of "-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing" and both packages build fine now (I'll have the fix up soon, just testing a few things first). Imagine issues with crossdev too but these two packages don't even build with out-of-the-box crossdev gcc in the first place (lto or not) and I hardly support that.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=681186074b74f271d43d680b920effa48c30eb0e commit 681186074b74f271d43d680b920effa48c30eb0e Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-06-28 05:08:14 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-06-28 05:55:31 +0000 dev-util/mingw64-toolchain: symlink gcc lto plugin for AR Don't really want to revbump this slow build over a symlink, but it could be a long time before this is bumped normally and come bite back when people try to use LTO. Closes: https://bugs.gentoo.org/854516 Closes: https://bugs.gentoo.org/854540 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> ...64-toolchain-10.0.0.ebuild => mingw64-toolchain-10.0.0-r1.ebuild} | 5 +++++ 1 file changed, 5 insertions(+)
care to explain how you injected lto into the dxvk ebuild? I can test if it works with crossdev born then.
(In reply to tt_1 from comment #7) > care to explain how you injected lto into the dxvk ebuild? > > I can test if it works with crossdev born then. Hm? Just emerge with C(XX)FLAGS="-flto ..." like any other packages, it does strip-unsupported-flags (given changing expected compiler) but that keeps -flto. Any issues are likely to be with crossdev rather than these packages, lto should now work out-of-the-box if mingw64-toolchain-10.0.0-r1 and USE=-crossdev-mingw (default).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e855eb72fd45d7a1cb013e658fdeb49636ffe7af commit e855eb72fd45d7a1cb013e658fdeb49636ffe7af Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-09-16 15:48:13 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-09-16 16:17:19 +0000 dev-util/mingw64-toolchain: fix lto again Was wondering why AR was looking for the lto plugin in a non-existing bfd-plugins directory before, turned out it was because gcc resolved its location differently when set as a symlink. In commit c4262506ff492b96cddccb15e1fe1842d8d5a626, reverted to using upstream's intended hardlink but didn't notice this change in behavior and it broke lto again. Bug: https://bugs.gentoo.org/854516 Fixes: c4262506ff492b96cddccb15e1fe1842d8d5a626 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> ...toolchain-10.0.0-r1.ebuild => mingw64-toolchain-10.0.0-r2.ebuild} | 5 ++--- ...lchain-10.0.0_p1.ebuild => mingw64-toolchain-10.0.0_p1-r1.ebuild} | 5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-)
