Bug 14138 - [QA 3.1.4 RC1] failure in oe-core manual test: test_bitbake_devshell
Summary: [QA 3.1.4 RC1] failure in oe-core manual test: test_bitbake_devshell
Status: RESOLVED INVALID
Alias: None
Product: Manual Testing
Classification: QA/Testing
Component: manual-testing (show other bugs)
Version: 3.1.4
Hardware: All x86_64
: Undecided normal
Target Milestone: ---
Assignee: Unassigned
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2020-12-01 08:51 UTC by Sangeeta Jain
Modified: 2020-12-02 01:47 UTC (History)
7 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
error capture (149.24 KB, image/png)
2020-12-01 08:51 UTC, Sangeeta Jain
no flags Details
error logs (13.94 KB, application/octet-stream)
2020-12-01 08:51 UTC, Sangeeta Jain
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sangeeta Jain 2020-12-01 08:51:19 UTC
Created attachment 4752 [details]
error capture

Following failure is observed in OE-core manual testcase.

Test steps:

1.	Clone poky (commit id: 424296bf9bb4bae27febf91bce0118df09ce5fa1)
2.	cd poky 
3.	source oe-init-build-env
4.	$ bitbake matchbox-desktop
Wait until package builds successfully.
5.   $bitbake matchbox-desktop -c devshell
A terminal with a shell prompt within the OpenEmbedded build environment will be opened
6.    Verify that "matchbox-desktop" binary file is not created under "src" directory
7.    Run command:./configure && make

Expected output: "matchbox-desktop" binary file was created successfully under "src" directory
Actual output:

configure: error: C compiler cannot create executables
  
 Tested with Gcc version: 9.3.0 and 7.5.0

QA analysis:  cross compilation is not working.
details of error: devshell. PNG
log: config.log
Comment 1 Sangeeta Jain 2020-12-01 08:51:55 UTC
Created attachment 4753 [details]
error logs
Comment 2 Ross Burton 2020-12-01 16:23:10 UTC
Core issue: ./configure: line 3023: x86_64-poky-linux-gcc: command not found
Comment 3 Steve Sakoman 2020-12-01 16:54:15 UTC
Is this expected to work with no parameters to configure?

I see the same error with no parameters, but if I use the same configure parameters used in a normal build the configure and make complete successfully:

# ./configure --build=x86_64-linux   --host=x86_64-poky-linux   --target=x86_64-poky-linux   --prefix=/usr   --exec_prefix=/usr   --bindir=/usr/bin   --sbindir=/usr/sbin   --libexecdir=/usr/libexec   --datadir=/usr/share   --sysconfdir=/etc   --sharedstatedir=/com   --localstatedir=/var   --libdir=/usr/lib   --includedir=/usr/include   --oldincludedir=/usr/include   --infodir=/usr/share/info   --mandir=/usr/share/man   --disable-silent-rules   --disable-dependency-tracking   --with-libtool-sysroot=/home/steve/builds/poky/build/tmp/work/core2-64-poky-linux/matchbox-desktop/2.2-r0/recipe-sysroot --enable-startup-notification --with-dbus --disable-static && make
Comment 4 Steve Sakoman 2020-12-01 18:06:21 UTC
Did this work in previous releases?
Comment 5 Khem Raj 2020-12-01 18:40:28 UTC
I think we have a general problem with this approach, when we call ./configure we are essentially asking to compile it for natively for the system its running on. Minimally you would need to specify --host=<target-triplet> argument to configure to let it know that we are cross compiling. Otherwise it will trigger detection mechanisms assuming that its building for same host and can run test programs to deduce things. Which is not going to work in a cross compile environment like what devshell is creating. so please call 

./configure --host=<HOST>

e.g.

./confgure --host=x86_64-poky-linux

to ensure that you are asking it to cross build.

please note that it will not be all you need, there might be more configure options you might need for different packages to work.

devshell exports all the needed options via environment variable called CONFIGUREOPTS

so please use 

./configure ${CONFIGUREOPTS}

and you will be good.
Comment 6 Steve Sakoman 2020-12-01 22:07:12 UTC
Khem is correct, I can confirm that using

./configure ${CONFIGUREOPTS}

works.  And this is essentially what I did in my previous comment.

Closing this as Resolved, Invalid since this is not expected to work as tested.
Comment 7 Sangeeta Jain 2020-12-02 01:47:07 UTC
In previous releases, it worked without any parameters if run on default machine, qemux86-64. On other machine passing only one parameter./configure  --host=x86_64-linux used to work.
./configure ${CONFIGUREOPTS} works here and should be the right way to test. Updating the testcase.