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.
Regards,
Arnaud
