On Mon, 2023-08-14 at 11:39 +0200, Frédéric Martinsons wrote:
> 
> 
> Le lun. 14 août 2023, 10:46, Richard Purdie
> <[email protected]> a écrit :
> > On Mon, 2023-08-14 at 09:30 +0200, Frédéric Martinsons wrote:
> > > 
> > > 
> > > On Sun, 13 Aug 2023 at 17:05, Richard Purdie
> > > <[email protected]> wrote:
> > > > On Sun, 2023-08-13 at 17:00 +0200, Frédéric Martinsons wrote:
> > > > > On Sun, 13 Aug 2023 at 16:53, Richard Purdie
> > > > > <[email protected]> wrote:
> > > > > > 
> > > > > > and a reproducibility failure:
> > > > > > 
> > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3355/steps/13/logs/stdio
> > > > > > 
> > > > > > which leads to:
> > > > > > 
> > > > > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230813-z_b2j3ha/packages/diff-html/
> > > > > > 
> > > > > 
> > > > > 
> > > > > Argh, this makes me remember
> > > > > of https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090
> > > > > Do you know if any of cargo based recipe is reproducible ?
> > > > > Should I add EXCLUDE_FROM_WORLD in cargo-c ?
> > > > 
> > > > At some point we're going to have to dive in and fix the
> > > > reproducibility issues so I'm reluctant to take more patches
> > > > with
> > > > that
> > > > set...
> > > > 
> > > 
> > > 
> > > It will hardly be doable to correct the reproducibility of rust
> > > packages since rust/cargo
> > > itself have issues upstream. I take a look and there are lot of
> > > open
> > > issues
> > > cargo: 
> > > https://github.com/rust-lang/cargo/issues?q=is%3Aissue+is%3Aopen+labe
> > > l%3AA-reproducibility+
> > > rust: 
> > > https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label
> > > %3AA-reproducibility
> > 
> > I believe there is one problematic reference left which causes
> > problems
> > for core rust. Fixing that issue would be the best place to start
> > and
> > then we can work from there.
> > 
> > We do already have a lot of good reproducibility pieces in the
> > toolchain so not every upstream bug will apply to us.
> 
> I'm afraid I do not see what is your point, can you elaborate please?
> What is the "problematic reference left which causes problems
> for core rust" you refer to? 

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875

There appeared to be one reference left in the binaries we couldn't
track down. If we fix that one reference, at least the main rust recipe
issues *should* be fixed.

> > > There was an RFC accepted back in may
> > > (https://github.com/rust-lang/rfcs/pull/3127) and implementation
> > > progress have a tracking issue in cargo
> > > (https://github.com/rust-lang/cargo/issues/12137) and in rust
> > > (https://github.com/rust-lang/rust/issues/111540).
> > > 
> > > Don't know if it will fix our root issue
> > > (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14875) but I
> > > don't
> > > see how to workaround all of that without this upstream work.
> > > 
> > > For cargo-c specific issues, I'll try to make things better (the
> > > TMPDIR in debug symbols) but I'm wondering
> > > something, reproducibility is  desirable for all generated
> > > artifacts
> > > or is it only for target ones ?  I mean, 
> > > the cargo-c is used in native so I'm wondering if making it
> > > native
> > > only would be acceptable ?
> > 
> > That would certainly avoid this issue. It would also make on target
> > testing of the functionality not possible.
> 
> The test I added is on the final binary generated (rust-c-lib-
> examble-bin), not cargo-c itself. So the target test would still be
> valid.

Ok, good.

> I tested a release build with a custom patch that strips debuginfo
> (strip="debug info" in Cargo.toml) and I do not have build path
> leaking in debug symbol anymore. I'll dig this up more and see if I
> can upstream that. 

Debug symbols should be relocated correctly if we pass the correct
compiler options. We usually prefer debug symbols to be present so we
can package them into the -dbg packages.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185931): 
https://lists.openembedded.org/g/openembedded-core/message/185931
Mute This Topic: https://lists.openembedded.org/mt/100715215/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to