On August 4, 2022 12:43 am, Arnaud Ferraris wrote: > > Hi, > > On Tue, 21 Jun 2022 11:56:43 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard > <frede...@fr.ibm.com> wrote: >> Hi Sylvestre, >> at first, I thought it may be a squeekboard coding issue too, but the fact >> that the >> same code breaks with rustc 1.59 and not 1.58 made me think of a >> regression (be it squeekboard 1.17.1 or 1.18.0). Also, only rust >> components where changed for this test : exact same gcc etc .. >> If rustc changed it's behaviour in between, at least the compiler would >> have given an advice or a tip. Anyway this does not occur on other >> architectures, so yes, I rather think it may be some thorny ppc64el >> regression on rustc side, but that is only an assumption. >> I'm no rust expert to maybe try a different layout of the code or maybe >> rust link option that could help and workaround that linking issue for >> the time being. >> >> F. > > I'm one of the maintainers of squeekboard, and can confirm this is > likely a regression in rustc 1.59.0 as I could successfully build with > 1.58.1 as well (using a ppc64el docker container). > > The issue happens when building a small binary (squeekboard-test-layout) > which uses only a small subset of the functions provided by the whole > rust library. However, it seems that on ppc64el the compiler tries to > resolve all symbols from the library, even those which aren't actually > used by the binary. > > It seems to only affect 1.59.0 though, as rustc >= 1.60.0 (installed > from rustup) doesn't exhibit the same behavior, so I assume we'll be > able to close this bug once a new enough version hits Debian.
FWIW, if you want to test - there is an MR open for updating Debian's rustc to 1.60 ;) https://salsa.debian.org/rust-team/rust/-/merge_requests/16