Hi Mathieu, I have sent a v4 which addresses the issues you reported:
- Replaced packagegroup-core-buildessential with "gcc g++ make" to fix the multilib symlinks conflict in lib64-core-image-sato-sdk - Excluded complex_int test (fails on riscv64) - Compiler is detected dynamically in run-ptest (works without symlinks) Best Regards, Pratik ________________________________________ From: Mathieu Dubois-Briand <[email protected]> Sent: Wednesday, May 13, 2026 1:31 PM To: Pratik Farkase; [email protected] Cc: [email protected] Subject: Re: [OE-core][PATCH v3] libffi: add ptest support On Wed May 13, 2026 at 10:27 AM CEST, Pratik Farkase wrote: > Hi Mathieu, > > I was able to reproduce the multilib symlinks conflict locally with the same > configuration. The root cause is that packagegroup-core-buildessential pulls > in > gcc-symlinks, g++-symlinks, and cpp-symlinks which conflict in multilib > images (both arches try to own /usr/bin/gcc). > > The fix is to replace: > RDEPENDS:${PN}-ptest += "packagegroup-core-buildessential" > with: > RDEPENDS:${PN}-ptest += "gcc g++ make" > > And update run-ptest to find the compiler dynamically rather than hardcoding > gcc/g++. I've verified this resolves the multilib conflict > -lib64-core-image-sato-sdk builds cleanly with the fix applied. Thanks. > > Once you've had a chance to reproduce the glib-2.0 locale selftest issue, > I'll send v4 addressing all three problems: > - glib-2.0 locale selftest issue > - Multilib symlinks conflict (use gcc/g++/make instead of packagegroup) > - complex_int exclusion (fails on riscv64) I failed to do that yesterday, and I won't have time to look at this in the coming days. As I said, it might be some other issue that just shows here. Send your v4 when you are ready, if we are a bit lucky we won't see this issue anymore. > > Best Regards, > Pratik > > ________________________________________ > From: Mathieu Dubois-Briand <[email protected]> > Sent: Wednesday, May 13, 2026 7:33 AM > To: Pratik Farkase; [email protected] > Cc: [email protected] > Subject: Re: [OE-core][PATCH v3] libffi: add ptest support > > On Tue May 12, 2026 at 5:16 PM CEST, Mathieu Dubois-Briand wrote: >> On Tue May 12, 2026 at 10:30 AM CEST, Pratik Farkase wrote: >>> Hi Mathieu, >>> >>> I tested v3 on qemux86-64 against current master and was unable to >>> reproduce the glib-2.0 locale or multilib symlinks failures. >>> >>> Could you share the steps or configuration you used to reproduce the >>> these two issues? That would help me investigate further. >>> >>> Best Regards, >>> Pratik >>> >> >> Hi Pratik, >> >> Regarding the multilib one, I just managed to reproduce it locally: >> >> Using tag oecore/autobuilder.yoctoproject.org/valkyrie/a-full-3808 from >> poky-ci-archive git: >> https://git.yoctoproject.org/poky-ci-archive/tag/?h=oecore/autobuilder.yoctoproject.org/valkyrie/a-full-3808 >> >> Default local.conf template, with these lines added: >> PACKAGE_CLASSES = "package_rpm package_deb package_ipk" >> OE_FRAGMENTS += 'core/yocto-autobuilder/multilib-x86-lib64' >> SANITY_TESTED_DISTROS = '' >> OEQA_TESTDISPLAY = ':1' >> OE_FRAGMENTS += 'core/yocto-autobuilder/autobuilder >> core/yocto-autobuilder/autobuilder-resource-constraints' >> EXTRA_IMAGE_FEATURES ?= 'allow-empty-password empty-root-password >> allow-root-login' >> OE_FRAGMENTS += 'machine/qemux86 distro/poky' >> >> Then: >> bitbake lib64-core-image-sato-sdk >> ... >> ERROR: lib64-core-image-sato-sdk-1.0-r0 do_rootfs: Could not invoke dnf. >> Command '...' returned 1: >> ... >> Running transaction check >> Transaction check succeeded. >> Running transaction test >> Error: Transaction test error: >> file /usr/bin/g++ conflicts between attempted installs of >> lib64-g++-symlinks-15.2.0-r0.x86_64 and g++-symlinks-15.2.0-r0.core2_32 >> file /usr/bin/cpp conflicts between attempted installs of >> cpp-symlinks-15.2.0-r0.core2_32 and lib64-cpp-symlinks-15.2.0-r0.x86_64 >> file /usr/bin/gcc conflicts between attempted installs of >> lib64-gcc-symlinks-15.2.0-r0.x86_64 and gcc-symlinks-15.2.0-r0.core2_32 >> >> I will try to reproduce the selftest failures. >> > > I don't have the selftest issue locally. We can assume it is some sstate > pollution for now, we will go back to it later if it happens again. > > -- > Mathieu Dubois-Briand, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- Mathieu Dubois-Briand, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#236978): https://lists.openembedded.org/g/openembedded-core/message/236978 Mute This Topic: https://lists.openembedded.org/mt/119212486/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
