All of lore.kernel.org
 help / color / mirror / Atom feed
* Yocto Bug 14965 - Need info on rmeta hash
@ 2023-02-07 16:58 sundeep.kokkonda
  2023-02-09  6:19 ` Alex Kiernan
  0 siblings, 1 reply; 3+ messages in thread
From: sundeep.kokkonda @ 2023-02-07 16:58 UTC (permalink / raw)
  To: '"Alex Kiernan"', 'Richard Purdie'
  Cc: openembedded-core, 'Randy MacLeod'

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Hello Alex,

 

I am working on Yocto bug 14965. There is a build failure happening during
rust build because of 2 rmeta files with different hashes are generated.

 

I found that the changes with below commit id causing the 2nd rmeta file
(libcore-c5fc82c620226960.rmeta) generation.

e33afcd0dc rust-common.bbclass: use built-in rust targets for -native builds

 

I am trying to find the changes in build which causing the generation of 2nd
rmeta with different hash. I gave 2 builds by with & without e33afcd0dc
commit changes.

*	I checked the sigdata of librsvg & libstd-rs in both builds and
those are identical.
*	The dependency files
(../build/tmp/work/core2-64-poky-linux/librsvg/2.54.5-r0/build/target/releas
e/deps/*.d) also analysed and the shown differences are only the changed
hash value (did not get any info on what is causing this change).
*	But, some interesting changes I observed in '.rustc_info.json' which
are related to e33afcd0dc commit. In this json file,

*	'host' tag changed from 'x86_64-linux-gnu' ->
'x86_64-unknown-linux-gnu',
*	an extra 'target_feature=\"fxsr\' is added, and
*	'rustc_fingerprint' has different values between 2 builds.



Since you know much about rust, can you let me know is there any way I can
check which exact changes are causing the hash to be changed? also, are the
above changes in json file will cause hash to be changed?

 

 

Thanks,

Sundeep K.

 


[-- Attachment #2: Type: text/html, Size: 10108 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Yocto Bug 14965 - Need info on rmeta hash
  2023-02-07 16:58 Yocto Bug 14965 - Need info on rmeta hash sundeep.kokkonda
@ 2023-02-09  6:19 ` Alex Kiernan
  2023-02-13  7:01   ` Sundeep KOKKONDA
  0 siblings, 1 reply; 3+ messages in thread
From: Alex Kiernan @ 2023-02-09  6:19 UTC (permalink / raw)
  To: sundeep.kokkonda; +Cc: Richard Purdie, openembedded-core, Randy MacLeod

Hi Sundeep

Not sure I can really help - at best I'm a novice rust user (albeit
with a team who are writing rust).

Looking at the source for rmeta generation
(https://github.com/rust-lang/rust/tree/master/compiler/rustc_metadata/src/rmeta)
it looks like it's really just a dump of internal state. So I'd expect
pretty much anything can cause it to change - running strings over a
couple of files I have here I see things like the compiler triple in
there and the paths to source files.

Given we're seeing this in libstd-rs, I wonder if this is really an
issue with how we're building libstd-rs - as far as I can tell the
(current) supported way to build it is as part of the whole compiler
build. Looking at the arch build by comparison its all in one pass,
albeit with no need for separate native/target complications:

https://github.com/archlinux/svntogit-packages/blob/packages/rust/trunk/PKGBUILD

Though I don't know how you'd fit that into our world.

On Tue, Feb 7, 2023 at 4:58 PM <sundeep.kokkonda@gmail.com> wrote:
>
> Hello Alex,
>
>
>
> I am working on Yocto bug 14965. There is a build failure happening during rust build because of 2 rmeta files with different hashes are generated.
>
>
>
> I found that the changes with below commit id causing the 2nd rmeta file (libcore-c5fc82c620226960.rmeta) generation.
>
> e33afcd0dc rust-common.bbclass: use built-in rust targets for -native builds
>
>
>
> I am trying to find the changes in build which causing the generation of 2nd rmeta with different hash. I gave 2 builds by with & without e33afcd0dc commit changes.
>
> I checked the sigdata of librsvg & libstd-rs in both builds and those are identical.
> The dependency files (../build/tmp/work/core2-64-poky-linux/librsvg/2.54.5-r0/build/target/release/deps/*.d) also analysed and the shown differences are only the changed hash value (did not get any info on what is causing this change).
> But, some interesting changes I observed in '.rustc_info.json' which are related to e33afcd0dc commit. In this json file,
>
> 'host' tag changed from 'x86_64-linux-gnu' -> 'x86_64-unknown-linux-gnu',
> an extra 'target_feature=\"fxsr\' is added, and
> ‘rustc_fingerprint’ has different values between 2 builds.
>
> Since you know much about rust, can you let me know is there any way I can check which exact changes are causing the hash to be changed? also, are the above changes in json file will cause hash to be changed?
>
>
>
>
>
> Thanks,
>
> Sundeep K.
>
>



-- 
Alex Kiernan


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Yocto Bug 14965 - Need info on rmeta hash
  2023-02-09  6:19 ` Alex Kiernan
@ 2023-02-13  7:01   ` Sundeep KOKKONDA
  0 siblings, 0 replies; 3+ messages in thread
From: Sundeep KOKKONDA @ 2023-02-13  7:01 UTC (permalink / raw)
  To: openembedded-core

[-- Attachment #1: Type: text/plain, Size: 2588 bytes --]

Hello Richard,

As we discussed, I checked the build by removing the variables (RUST_BUILD_SYS, RUST_HOST_SYS & RUST_TARGET_SYS) from BB_BASEHASH_IGNORE_VARS in meta/conf/bitbake.conf file but this doesn't solve the issue, still 2 rmeta files generated.

So, I did a re-check of my analysis w.r.t to commit id - ' e33afcd0dc rust-common.bbclass: use built-in rust targets for -native builds '. The 2 nd rmeta file is generating by this commit id only and as mentioned earlier there is no diff in the generated sigdata files of libstd-rs & librsvg with this change.

May be removing vars form BB_BASEHASH_IGNORE_VARS is not a right fix?

FYI... See below generated rmeta files with and without e33afcd0dc.

> 
> :/3565ea860a-> git reflog
> 3565ea860a (HEAD) HEAD@{0}: checkout: moving from master to 3565ea860a
> aa6cd06a9f (origin/master, origin/HEAD, master) HEAD@{1}: clone: from
> git://git.yoctoproject.org/poky
> :/3565ea860a-> ls
> build/tmp/work/core2-64-poky-linux/librsvg/2.54.5-r0/recipe-sysroot/usr/lib/rustlib/x86_64-poky-linux-gnu/lib/
> | grep libcore
> libcore- 5c7322bf8f654199.rlib
> libcore- 5c7322bf8f654199.rmeta
> 

> 
> :/e33afcd0dc-> git reflog
> e33afcd0dc (HEAD) HEAD@{0}: checkout: moving from master to e33afcd0dc
> aa6cd06a9f (origin/master, origin/HEAD, master) HEAD@{1}: clone: from
> git://git.yoctoproject.org/poky
> :/e33afcd0dc-> ls
> build/tmp/work/core2-64-poky-linux/librsvg/2.54.5-r0/recipe-sysroot/usr/lib/rustlib/x86_64-poky-linux-gnu/lib/
> | grep libcore
> libcore- c5fc82c620226960.rlib
> libcore- c5fc82c620226960.rmeta
> 

Sigdata diff:

> 
> :/e33afcd0dc-> diff -ur build/tmp/stamps/core2-64-poky-linux/libstd-rs/
> ../3565ea860a/build/tmp/stamps/core2-64-poky-linux/libstd-rs/
> Binary files
> build/tmp/stamps/core2-64-poky-linux/libstd-rs/1.64.0-r0.do_compile.sigdata.58c969bdc47351ac51bd19dd76f57855e14940a04ff9bdfbfc5cb92a27172da8
> and
> ../3565ea860a/build/tmp/stamps/core2-64-poky-linux/libstd-rs/1.64.0-r0.do_compile.sigdata.58c969bdc47351ac51bd19dd76f57855e14940a04ff9bdfbfc5cb92a27172da8
> differ
> ....
> ....
> Binary files
> build/tmp/stamps/core2-64-poky-linux/libstd-rs/1.64.0-r0.do_unpack.sigdata.1203b8d6806ffeb75970f492ece3eaa91c51a79eb411eb075946c482239a69d5
> and
> ../3565ea860a/build/tmp/stamps/core2-64-poky-linux/libstd-rs/1.64.0-r0.do_unpack.sigdata.1203b8d6806ffeb75970f492ece3eaa91c51a79eb411eb075946c482239a69d5
> differ
> 

I checked the dumpsig of the above shown differences and the changes are only in the name of build directory.

Thanks,
Sundeep K.

[-- Attachment #2: Type: text/html, Size: 13455 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-02-13  7:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-02-07 16:58 Yocto Bug 14965 - Need info on rmeta hash sundeep.kokkonda
2023-02-09  6:19 ` Alex Kiernan
2023-02-13  7:01   ` Sundeep KOKKONDA

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.