All versions of dav1d in-tree currently seems broken with lto, 0.9.0, 0.8.2, 0.8.0 Using clang+lto https://code.videolan.org/videolan/dav1d/-/issues/362 might be relevant. Clang+no-lto works. No clue about gcc+lto.
Probably a dupe of bug #791544. Tl;DR is: dav1d greps raw ELF to detect platform properties.
Ah, your link is about runtime failures. Never mind me.
Yes, it compiles fine, but runtime segfaults. The link seems to state that gcc+lto is fine too, so it's somehow clang+lto related.
Seems like +clang -lto works fine. So I suggest to check if tc-is-clang && is-flagq "-flto*" -> strip lto out with filter-flags "-flto*", and post some elog to user about it. Since the breakage happens in runtime, and not in build-time.
Looking at the upstream bug report, this seems resolved in 1.0.0. So bug can be closed when 1.0.0 is stabilized and <1.0.0 cleaned, I guess.
(In reply to Joonas Niilola from comment #5) > Looking at the upstream bug report, this seems resolved in 1.0.0. So bug can > be closed when 1.0.0 is stabilized and <1.0.0 cleaned, I guess. I don't believe I ever got round to filing a Gentoo bug related to the dav1d one. The fix was to pass through `-Dstack_alignment=16` to emesonargs when tc-is-clang + lto. Nothing was changed on dav1d's side as from their point of view it's a clang bug. https://github.com/llvm/llvm-project/issues/39981 https://github.com/llvm/llvm-project/issues/40602
(In reply to James Beddek from comment #6) > (In reply to Joonas Niilola from comment #5) > > Looking at the upstream bug report, this seems resolved in 1.0.0. So bug can > > be closed when 1.0.0 is stabilized and <1.0.0 cleaned, I guess. > > I don't believe I ever got round to filing a Gentoo bug related to the dav1d > one. The fix was to pass through `-Dstack_alignment=16` to emesonargs when > tc-is-clang + lto. Nothing was changed on dav1d's side as from their point > of view it's a clang bug. > > https://github.com/llvm/llvm-project/issues/39981 > https://github.com/llvm/llvm-project/issues/40602 If they consider it a clang bug, then why did they close it saying it's resolved? If it *is* a clang bug, maybe it's still worth it on their end to automatically force acceptable options when clang is detected as the compiler?
