Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2022-07-18 at 21:07 -0300, Otavio Salvador wrote:
> Em seg., 18 de jul. de 2022 às 19:54, Richard Purdie
> <richard.purdie@linuxfoundation.org> escreveu:
> > On Mon, 2022-07-18 at 18:41 -0300, Otavio Salvador wrote:
> > > Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie
> > > <richard.purdie@linuxfoundation.org> escreveu:
> > > > > It does, indeed, but it doesn't seem related to this PR. 
> > > > > 
> > > > > Do you know if this has worked?
> > > > > 
> > > > > I am asking as I did all development and testing
> > > > > using SDKMACHINE
> > > > > ?=
> > > > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine.
> > > > > However,
> > > > > looking at some of the logs above, it seems it is using an
> > > > > SDKMACHINE
> > > > > as i686, so this appears as a different issue for me.
> > > > > 
> > > > 
> > > > rust-cross-canadian hasn't officially worked properly or been
> > > > supported. In assessing whether a patch is better or worse, it
> > > > is
> > > > useful to know which cases regress and which improve. I had
> > > > hoped
> > > > this
> > > > list of failures would be smaller. I will admit I don't know
> > > > whether
> > > > this is better or worse than before so I guess that is the next
> > > > thing I
> > > > need to determine.
> > > > 
> > > 
> > > 
> > > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and
> > > this
> > > worked.
> > > 
> > > > What we don't know right now is which combinations work and
> > > > which
> > > > don't
> > > > so we can't even tell people what is expected to work and what
> > > > isn't/doesn't :(
> > > > 
> > > 
> > > 
> > > See above.
> > >  
> > > > I mentioned this report in case someone can work out the
> > > > pattern,
> > > > or
> > > > even better, understand what a fix looks like...
> > > > 
> > > 
> > > 
> > > I am not familiar enough to Rust boostrap to help here but we
> > > spent a
> > > lot of time to get the SDK working and I think this is a step on
> > > the
> > > right direction, at least.
> > 
> > Thanks, I do appreciate the patches. I think we've talked cross
> > purposes as I did report my aarch64 test case issue previously and
> > I
> > thought this series was to attempt to fix things so the recipe did
> > work
> > generically.
> > 
> 
> 
> I had it fixed to SDKMACHINE as x86_64 on a x86_64. I didn't realise
> it was using a different SDKMACHINE.
> 
> > If I merge this to fix x86_64, I think people will then just ignore
> > the
> > other cases and things will remain broken there which worries me a
> > lot
> > and means we can't generically enable rust SDKs for the project and
> > gain autobuilder testing to spot future regressions.
> > 
> 
> 
> I understand.
>  
> > Obviously you want your use case fixed though. I will try and
> > evaluate
> > things a bit more tomorrow. What I don't want to do is merge a fix
> > which then makes it harder to get things correctly done in future
> > though, particularly when I know there will be an instant backport
> > request to an LTS as soon as I accept it for master.
> > 
> 
> 
> In fact I need patch 1/2 as this fixes our use case. We worked on 2/2
> (this patch) for completeness.
>  
> > We never should have accepted these rust cross-canadian recipes at
> > all
> > as they are just broken :(.
> 
> Agreed.
>  

I've done a bit more work on this and the more I dig, the more I think
we have some issues we need to sort with taking a step back and
checking some assumptions.

What I'm lacking is a good way to test the resulting rust toolchain.
Would someone with some rust knowledge be able to add something to
meta/lib/oeqa/sdk/cases/ which tested rust in the SDK?

If someone can add some rust tests in the SDK, I think I might have an
idea of what the patches look like to properly fix the rust toolchain
there.

Cheers,

Richard