RSS-related problem after update to OE-Core with dnf

RSS-related problem after update to OE-Core with dnf

[Peter Kjellerstedt]

I update my Poky to the latest on master yesterday (i.e., I went from 
a version using smart to one using dnf) and when I rebuilt my image I 
got the following error:

| cd ${WORKDIR}/build/ext && ${WORKDIR}/recipe-sysroot-native/usr/bin/cmake -E cmake_link_script CMakeFiles/libsolvext.dir/link.txt --verbose=1
| ${WORKDIR}/recipe-sysroot-native/usr/bin/mipsel-poky-linux/mipsel-poky-linux-gcc  -fPIC -mel -mabi=32 -msoft-float -march=34kc -msynci  --sysroot=${WORKDIR}/recipe-sysroot  -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=${WORKDIR}=/usr/src/debug/libsolv/0.6.26-r0 -fdebug-prefix-map=${WORKDIR}/recipe-sysroot-native= -fdebug-prefix-map=${WORKDIR}/recipe-sysroot=  -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -mel -mabi=32 -msoft-float -march=34kc -msynci  --sysroot=${WORKDIR}/recipe-sysroot -Wall -fPIC -Wl,-O1  -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now  -Wl,--version-script=${WORKDIR}/git/ext/libsolvext.ver -shared -Wl,-soname,libsolvext.so.0 -o libsolvext.so.0 CMakeFiles/libsolvext.dir/solv_xfopen.o CMakeFiles/libsolvext.dir/testcase.o CMakeFiles/libsolvext.dir/pool_fileconflicts.o CMakeFiles/libsolvext.dir/repo_rpmdb.o CMakeFiles/libsolvext.dir/repo_repomdxml.o CMakeFiles/libsolvext.dir/repo_rpmmd.o CMakeFiles/libsolvext.dir/repo_deltainfoxml.o CMakeFiles/libsolvext.dir/repo_updateinfoxml.o -Wl,-rpath,${WORKDIR}/build/src:${WORKDIR}/recipe-sysroot-native/usr/lib: ../src/libsolv.so.0 -Wl,--as-needed -ldb -lrpmio ${WORKDIR}/recipe-sysroot-native/usr/lib/librpmdb.so -lexpat -lz
| ${WORKDIR}/recipe-sysroot-native/usr/lib/librpmdb.so: error adding symbols: File in wrong format

When I ran file on librpmdb.so it showed:

$ file ${WORKDIR}/recipe-sysroot-native/usr/lib/librpmdb-5.4.so
${WORKDIR}/recipe-sysroot-native/usr/lib/librpmdb-5.4.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xb49c3f89085d16c65bb443622e68cbbfdae605cb, stripped

I.e., it is trying to link a MIPS library with an x86_64 one...

After I did a "bitbake libsolv -c cleansstate", the problem went away, 
and checking the log.do_compile afterwards it seems it is not even 
trying to link with librpmdb.so at all any more.

My guess is that the librpmdb.so (which was a link to librpmdb-5.4.so) 
was a leftover from before the switch from smart to dnf. However, the 
fact that it remained in ${WORKDIR}/recipe-sysroot-native AND that it 
was picked up by the build indicates both a problem with the 
determinism of RSS, and the with the build of libsolv itself.

//Peter

Re: RSS-related problem after update to OE-Core with dnf

[Richard Purdie]

On Wed, 2017-03-15 at 09:29 +0000, Peter Kjellerstedt wrote:
> I update my Poky to the latest on master yesterday (i.e., I went
> from 
> a version using smart to one using dnf) and when I rebuilt my image
> I 
> got the following error:
> [...]
> I.e., it is trying to link a MIPS library with an x86_64 one...
> 
> After I did a "bitbake libsolv -c cleansstate", the problem went
> away, 
> and checking the log.do_compile afterwards it seems it is not even 
> trying to link with librpmdb.so at all any more.
> 
> My guess is that the librpmdb.so (which was a link to librpmdb-
> 5.4.so) 
> was a leftover from before the switch from smart to dnf. However,
> the 
> fact that it remained in ${WORKDIR}/recipe-sysroot-native AND that
> it 
> was picked up by the build indicates both a problem with the 
> determinism of RSS, and the with the build of libsolv itself.

FWIW I have read this and it is a concern. Unfortunately RSS is just
that, *recipe* specific, not task specific and therefore as I mentioned
in the original commits, it can't be perfect as it doesn't know
anything about the dependencies of other tasks this recipe may have and
which may be running in parallel.

I'm contiuing to see if there are better ways we can ensure stale
things get removed from the sysroots but its a hard problem due to the
parallelism. I do have some ideas though.

Distilling an easy to reproduce test case would help if someone has the
time.

Cheers,

Richard