diff mbox series

oeqa/sdk/cases/autotools.py: fix host_sys value to handle multilib case

Message ID 20251104033329.466996-1-Qi.Chen@windriver.com
State New
Headers show
Series oeqa/sdk/cases/autotools.py: fix host_sys value to handle multilib case | expand

Commit Message

ChenQi Nov. 4, 2025, 3:33 a.m. UTC 
From: Chen Qi <Qi.Chen@windriver.com>

For now, testsdk always fails for multilib. This could be reproduced
by the following steps:

  1. Add to local.conf:
     OE_FRAGMENTS += "machine/qemux86-64 distro/poky"
     OE_FRAGMENTS += "core/yocto-autobuilder/multilib-x86-lib32"
     IMAGE_CLASSES += "testsdk"
  2. bitbake core-image-minimal -c populate_sdk && \
     bitbake core-image-minimal -c testsdk

This is because in case of multilib, HOST_SYS value is not correct.

So switch to use CONFIGURE_FLAGS environment variable to extract
the host_sys value.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/lib/oeqa/sdk/cases/autotools.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Alexander Kanavin Nov. 4, 2025, 1:12 p.m. UTC | #1 
On Tue, 4 Nov 2025 at 04:33, Chen Qi via lists.openembedded.org
<Qi.Chen=windriver.com@lists.openembedded.org> wrote:
> This is because in case of multilib, HOST_SYS value is not correct.

Can you please give an example of the incorrect value, and what it
should be. We probably can find a better way to obtain the correct
value than surgery on CONFIGURE_FLAGS.

Alex
ChenQi Nov. 5, 2025, 2:40 a.m. UTC | #2 
On 11/4/25 21:12, Alexander Kanavin wrote:
> On Tue, 4 Nov 2025 at 04:33, Chen Qi via lists.openembedded.org
> <Qi.Chen=windriver.com@lists.openembedded.org> wrote:
>> This is because in case of multilib, HOST_SYS value is not correct.
> Can you please give an example of the incorrect value, and what it
> should be. We probably can find a better way to obtain the correct
> value than surgery on CONFIGURE_FLAGS.
>
> Alex

Hi Alex,

When getting host_sys from td["HOST_SYS"], the value is always 
x86_64-poky-linux. This value is correct for 
environment-setup-x86-64-v3-poky-linux. But for 
environment-setup-x86-pokymllib32-linux, it's not correct. The correct 
value is i686-pokymllib32-linux.

P.S.
In that test case, the check runs after:
self._run("cd {build} && {source}/configure CFLAGS='-std=gnu17 
-Dbool=int -Dtrue=1 -Dfalse=0 -Wno-error=implicit-function-declaration' 
$CONFIGURE_FLAGS".format(**opts))
So I guess the initial intention is to ensure $CONFIGURE_FLAGS actually 
takes effect.

Regards,
Qi
Alexander Kanavin Nov. 5, 2025, 10:15 a.m. UTC | #3 
On Wed, 5 Nov 2025 at 03:40, ChenQi <Qi.Chen@windriver.com> wrote:
> When getting host_sys from td["HOST_SYS"], the value is always
> x86_64-poky-linux. This value is correct for
> environment-setup-x86-64-v3-poky-linux. But for
> environment-setup-x86-pokymllib32-linux, it's not correct. The correct
> value is i686-pokymllib32-linux.

Right, what I was trying to find out is if there's some place where
that value can be obtained directly. As far as I see, CONFIGURE_FLAGS
is set in meta/classes-recipe/toolchain-scripts.bbclass, and there's
no separate variable holding the correct value. So the patch seems ok.

Alex
diff mbox series

Patch

diff --git a/meta/lib/oeqa/sdk/cases/autotools.py b/meta/lib/oeqa/sdk/cases/autotools.py
index ecafafa7d6..b9dd125294 100644
--- a/meta/lib/oeqa/sdk/cases/autotools.py
+++ b/meta/lib/oeqa/sdk/cases/autotools.py
@@ -43,7 +43,8 @@  class AutotoolsTest(OESDKTestCase):
 
             # Check that configure detected the target correctly
             with open(os.path.join(opts["build"], "config.log")) as f:
-                host_sys = self.td["HOST_SYS"]
+                configure_flags= self._run("echo $CONFIGURE_FLAGS")
+                host_sys = configure_flags.split("--host=")[1].split()[0]
                 self.assertIn(f"host_alias='{host_sys}'\n", f.readlines())
 
             self._run("cd {build} && make CFLAGS='-std=gnu17 -Dbool=int -Dtrue=1 -Dfalse=0 -Wno-error=implicit-function-declaration' {parallel_make}".format(**opts))