On Mon, Jan 9, 2023 at 7:02 AM Kokkonda, Sundeep <[email protected]> wrote: > > Hello Alex, > > I found a few below listed deviations in Yocto's (with rust recipe) build > environment w.r.t 'rust' (rust cloned from github) build environment. Do you > know why these deviations in Yocto's rust linker? >
Sorry, ended up reading these messages out of order... > > Thanks, > Sundeep K. > ________________________________ > From: Kokkonda, Sundeep > Sent: 03 January 2023 21:29 > To: [email protected] <[email protected]> > Cc: MacLeod, Randy <[email protected]>; Moodalappa, Shivaprasad > <[email protected]> > Subject: Bug 14875 - reproducibility issue queries > > Hello Richard, > > On the rust reproducibility issue, as we discussed I tried to compile the > libs outside of Yocto to generate the lib. > > I took the compiler command of a crate from the 'bitbake -vv rust' log (refer > attached file), but the compilation shows several errors... > > (Eg. missing ofenv variables RUSTC_STAGE, RUSTC_SYSROOT, RUSTC_SNAPSHOT, > RUSTC_SNAPSHOT_LIBDIR, RUSTC_REAL, RUSTC_LIBDIR... I read all env vars during > Yocto rust execution but the env list doesn't show any of these vars. > Somehow, I exported these vars but the build shows other errors from *.rs > source files). > Is it the way you want me to do? > > Since the --remap-path-prefix cmd is passed during compilation, I suspect the > issue is not with compiler and tried below alternate methods to find the > issue and have some queries... It'll be helpful if you've any inputs on below > points... > > Since the librustc_driver*.so binary differed in '.rustc' linker section, I > disassembled all generated objects (including the objects in .rlib libraries) > to identify from which object the assembly difference is coming. But, in any > of these disassembled files the '.rustc' section is not present. Could not > find any linker script which groups some input sections to .rustc output > section. I suspect there is 'link.rs' file which is making this linker > section, going through the code... > > I found a difference in linking of libs in Yocto project when compared to > normal rust environment. In rust, there is no linker flag '-C linker' is > passed, but Yocto uses below extra linker parameters. Maybe we are linking > objects differently than rust used linker? > -C > linker=/home/skokkonda/yocto/poky/buildA/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/wrapper/build-rust-ccld > -L > native=/home/skokkonda/yocto/poky/buildA/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/recipe-sysroot-native/usr/lib/llvm-rust/lib > -L > native=/home/skokkonda/yocto/poky/buildA/tmp/work/x86_64-linux/rust-llvm-native/1.66.0-r0/recipe-sysroot-native/usr/lib > -L > native=/home/skokkonda/yocto/poky/buildA/tmp/work/x86_64-linux/rust-llvm-native/1.66.0-r0/recipe-sysroot-native/lib > > In rust, the librustc_driver*.so is generated during stage-0 and the same lib > copied to stage-2 output. But, as per Yocto build log shows > librustc_driver*.so is re-generated at every build stage. > That strikes me as interesting - I wondered if our builds did something like that. This upstream ticket looked interesting too https://github.com/rust-lang/rust/issues/98185 I'm afraid I've no real insight into the issue though. -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175679): https://lists.openembedded.org/g/openembedded-core/message/175679 Mute This Topic: https://lists.openembedded.org/mt/96147825/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
