On Wed, 2022-06-29 at 15:08 +0200, Tomasz Dziendzielski wrote:
> If we have the build with different gcc versions in the same workspace
> it might happen that nativesdk recipe will not detect the change of gcc
> and the package will be taken from sstate-cache. This will lead to
> do_package_qa failure due to binaries requiring symbols that are not
> present in the older libstdc++.
>
> Example error:
> > ERROR: nativesdk-mgen-1.0-r0 do_package_qa: QA Issue:
> > /opt/poky/3.2.3/sysroots/x86_64-pokysdk-linux/usr/lib/libssh2pp.so.0.1
> > contained in package nativesdk-mgen requires
> > libstdc++.so.6(GLIBCXX_3.4.11)(64bit), but no providers found in
> > RDEPENDS_nativesdk-mgen? [file-rdeps]
>
> Add vardeps dependency to GCCVERSION to make sure the package is rebuild
> with correct gcc version.
>
> Signed-off-by: Tomasz Dziendzielski <tomasz.dziendziel...@gmail.com>
> Signed-off-by: Jan Brzezanski <jan.brzezan...@gmail.com>
> ---
> meta/classes/base.bbclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index cc02de5f77..da2dc05bba 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -148,6 +148,7 @@ do_fetch[dirs] = "${DL_DIR}"
> do_fetch[file-checksums] = "${@bb.fetch.get_checksum_file_list(d)}"
> do_fetch[file-checksums] += " ${@get_lic_checksum_file_list(d)}"
> do_fetch[vardeps] += "SRCREV"
> +do_fetch[vardeps] += "GCCVERSION"
> do_fetch[network] = "1"
> python base_do_fetch() {
>
We're definitely not doing that, it is incorrect on many different
levels (e.g. fetching is not dependent on the target compiler version
just for starters). You also just made all native recipes rebuild for
the target GCC version too, which again, is just wrong.
Building with a different target gcc version should mean all the sstate
checksums change. I'm guessing what has happened in your case is that a
TMPDIR as reused after changing gcc version but something didn't
rebuild, probably as ${S} == ${B} and hence ${B} couldn't be cleaned.
We should really track down where the corruption came in and improve
the build output isolation of wherever that came from.
Worse is that your "fix" above probably won't even solve the problem as
if you repeat your build workflow where this broke originally, I'd
strongly suspect it will still break with that change above too.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167378):
https://lists.openembedded.org/g/openembedded-core/message/167378
Mute This Topic: https://lists.openembedded.org/mt/92064206/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
