https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-util/bugbite-cli-0.0.12 fails to compile. Discovered on: amd64 (internal ref: lto_tinderbox) System: LTO-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#LTO) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0014
Created attachment 906629 [details] build.log build log and emerge --info
Haven't thoroughly checked so I could've overlooked something, but seems to only fail when tests are enabled and with rust-1.82 (fine for me with rust-bin-1.81.0). More specifically it's building something in src_test and failing there.
(In reply to Ionen Wolkens from comment #2) > rust-1.82 (as arthurzam pointed on IRC, might be related to rust newly using llvm19)
Since all linking works as expected and tests pass upstream with rust-1.82 this is likely a Gentoo related issue with how the toolchain handles lto possibly coupled with some upstream linking changes that got stabilized in rust-1.82. Probably could also involve upstream CI not using the same compiler/linker for C code when building rust crates. Someone could try running tests on Gentoo with lto disabled with rust-1.82 to see if that is indeed causing the issue. It's also possible to make the TLS provider configurable and avoid using ring (which is currently the main cause of the linking errors), but since the upstream library bugbite uses for HTTP support still defaults to it, I'm hesitant to add generally unnecessary build complexity.
Hitting this while attempting revbumps for upcoming slotted rust / cargo eclass changes - 1.82.0 from source. I've restricted the ebuild from selecting the new 1.82.0 slot (so only 1.79.0, 1.81.0 are valid). I note that my 1.81.0 is -bin but based on the ticket that should be fine.
Huh. Nope. Seeing the same thing on 1.81.0-bin. /me shrugs
Created attachment 908042 [details] build log with 1.81.0 rust bin
As I expected, after testing this locally it works fine and tests pass with rust-1.82 and 14.2.0 on Gentoo so it seems like it's related to what gcc version is being used since rustc uses that for linking by default.
fwiw I can't reproduce anymore, no idea what changed beside I do have a bit newer gcc than last time (current 14.2.1_p20241026), I wasn't using gcc-15.
