Date   

Re: #yocto debbuging option under zeus #yocto

Khem Raj
 

On 8/11/21 3:53 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Is it documented anywhere on how one might manually load debug info an for image with the binaries stripped ?
what you are looking for is perhaps achieved better by setting a feedserver on your buildmachine and then let your target download/update packages much like other distributions

in local.conf set

PACKAGE_FEED_URIS = "http://10.0.0.10:8000"

this would encode the feedserver address into you online package manager config in image

then run

bitbake package-index

which would update the feed metadata index

Run a http-server on the feed directory on buildserver

a poor man's way is

cd build/tmp/deploy/ipk/
python -m http.server

then you can go to your target and do normal opkg operations


opkg update && opkg install busybox-dbg

another advantage of this approach is that it will automatically download/install the dependecies.



Thanks,
Steve
*From:* yocto@... <yocto@...> *On Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
*Sent:* Tuesday, August 10, 2021 1:48 PM
*To:* yocto@...
*Subject:* [yocto] #yocto debbuging option under zeus
*_External Email Alert_*
*This email has been sent from an account outside of the BAE Systems network.*
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.
I ran across the following under the Yocto Project Profiling and Tracing Manual, and after checking my ipk data files/layout, I was wondering if someone could tell me, if ipk is capable of performing a similar set of operations to install my debug data ?, and if so, what would be the correct command sequence ?
“ The debug packages once built can be found in build/tmp/deploy/rpm/* on the host system. Find the busybox-dbg-...rpm file and copy it to the target. For example:
[trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2r2.core2_32.rpm root@....31 <mailto:root@....31>:
root@....31's <mailto:root@....31's> password:
     busybox-dbg-1.20.2-r2.core2_32.rpm                     100% 1826KB   1.8MB/s   00:01
Now install the debug rpm on the target:
     root@crownbay:~# *rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm*

Thanks,
Steve


Re: Unable to add gdbserver to the Yocto build #yocto

Alexander Kanavin
 

Can you check whether the gdbserver package is in tmp/work/.../gdb/deploy-*/ (the gdb WORKDIR), and whether it is in tmp/deploy/... (packages deploy dir), and then whether it is in tmp/work/..../machine-image/ (image-specific package repo)? Seems like it gets lost at some point.

Alex


On Thu, 12 Aug 2021 at 17:24, Ashutosh Naik <ashutosh.naik@...> wrote:
HI Alexander,

Thanks for your email.

The  'bitbake gdb' runs through successfully. However, I still get the error for gdbserver when running 'bitbake machine-image'

Thanks
Ash

On Thu, Aug 12, 2021 at 3:54 PM Alexander Kanavin <alex.kanavin@...> wrote:
What happens when you 'bitbake gdb'?

Alex

On Thu, 12 Aug 2021 at 16:28, <ashutosh.naik@...> wrote:
 
I added the following to EXTRA_IMAGE_FEATURES inside my local.conf, 
 
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-debug"
PACKAGECONFIG_remove_pn-gdb = "readline"
 
I also tried to add the gdbserver package explicitly by adding this to conf/local.conf:
 
IMAGE_INSTALL_append = " gdbserver"
 
However, the build failed with the following error:
 
Collected errors:
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - nothing provides gdbserver needed by packagegroup-core-tools-debug-1.0-r3.all
 * 
 * Solution 1:
 *   - do not ask to install a package providing packagegroup-core-tools-debug
 
Would appreciate any help, as I am struggling with this issue for over a day
 
Thanks
Ash




Re: Unable to add gdbserver to the Yocto build #yocto

Ashutosh Naik
 

HI Alexander,

Thanks for your email.

The  'bitbake gdb' runs through successfully. However, I still get the error for gdbserver when running 'bitbake machine-image'

Thanks
Ash

On Thu, Aug 12, 2021 at 3:54 PM Alexander Kanavin <alex.kanavin@...> wrote:
What happens when you 'bitbake gdb'?

Alex

On Thu, 12 Aug 2021 at 16:28, <ashutosh.naik@...> wrote:
 
I added the following to EXTRA_IMAGE_FEATURES inside my local.conf, 
 
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-debug"
PACKAGECONFIG_remove_pn-gdb = "readline"
 
I also tried to add the gdbserver package explicitly by adding this to conf/local.conf:
 
IMAGE_INSTALL_append = " gdbserver"
 
However, the build failed with the following error:
 
Collected errors:
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - nothing provides gdbserver needed by packagegroup-core-tools-debug-1.0-r3.all
 * 
 * Solution 1:
 *   - do not ask to install a package providing packagegroup-core-tools-debug
 
Would appreciate any help, as I am struggling with this issue for over a day
 
Thanks
Ash




Minutes: Yocto Project Weekly Triage Meeting 8/12/2021

Randy MacLeod
 

*Wiki: *https://wiki.yoctoproject.org/wiki/Bug_Triage

*Attendees:* Alex, Diane, Joshua, MichaelO, Randy, Saul, Stephen, Steve, Tim, Tony, Ross

*ARs:*

Deal with old milestones:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone

1. Ross
2. Bruce

FYI: AR = Action Required according to Google's top hit:

http://www.nathanzeldes.com/wp-content/uploads/2014/01/Effective-Action-Culture.pdf



*Notes:*
*
*
- (carried over) Steve encountered build failures such as the one in https://errors.yoctoproject.org/Errors/Details/593109/ when attempting to run dunfell builds with the PARALLEL_MAKE load averaging added. WR is testing/investigating on internal Autobuilder instance

- No Future/3.99 bugs to triage this week (wow!)

*Medium+ 3.4 Unassigned Enhancements/Bugs: *80* (No change)

*Medium+ 3.99 Unassigned Enhancements/Bugs: *30* (Last week 30)

*AB-INT Bugs: *46* (No change)


Re: Unable to add gdbserver to the Yocto build #yocto

Alexander Kanavin
 

What happens when you 'bitbake gdb'?

Alex


On Thu, 12 Aug 2021 at 16:28, <ashutosh.naik@...> wrote:
 
I added the following to EXTRA_IMAGE_FEATURES inside my local.conf, 
 
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-debug"
PACKAGECONFIG_remove_pn-gdb = "readline"
 
I also tried to add the gdbserver package explicitly by adding this to conf/local.conf:
 
IMAGE_INSTALL_append = " gdbserver"
 
However, the build failed with the following error:
 
Collected errors:
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - nothing provides gdbserver needed by packagegroup-core-tools-debug-1.0-r3.all
 * 
 * Solution 1:
 *   - do not ask to install a package providing packagegroup-core-tools-debug
 
Would appreciate any help, as I am struggling with this issue for over a day
 
Thanks
Ash




Unable to add gdbserver to the Yocto build #yocto

Ashutosh Naik
 

 
I added the following to EXTRA_IMAGE_FEATURES inside my local.conf, 
 
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-debug"
PACKAGECONFIG_remove_pn-gdb = "readline"
 
I also tried to add the gdbserver package explicitly by adding this to conf/local.conf:
 
IMAGE_INSTALL_append = " gdbserver"
 
However, the build failed with the following error:
 
Collected errors:
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - nothing provides gdbserver needed by packagegroup-core-tools-debug-1.0-r3.all
 * 
 * Solution 1:
 *   - do not ask to install a package providing packagegroup-core-tools-debug
 
Would appreciate any help, as I am struggling with this issue for over a day
 
Thanks
Ash


Re: [meta-openssl102-fips][PATCH 1/3] layer.conf: add honister to LAYERSERIES_COMPAT

Jason Wessel <jason.wessel@...>
 

All three patches have been merged and a hardknott branch was split off prior to the merges of change set.

Cheers,

Jason.

On 8/6/21 2:13 AM, Yi Zhao wrote:
Signed-off-by: Yi Zhao <yi.zhao@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 01026f0..fc1dcbd 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two-fips = "5"
LAYERVERSION_meta-openssl-one-zero-two-fips = "1"
-LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "hardknott"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "honister"
LAYERPATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}"


Re: RTC issue

Matthias Klein
 

Hello Jupiter,

How did you disable snvs_rtc? My device tree to include imx6ull.dtsi which don't have snvs_rtc, only has snvs-rtc-lp, so I added status = "disabled"; to the snvs-rtc-lp node:

snvs-rtc-lp {
compatible = "fsl,sec-v4.0-mon-rtc-lp";
regmap = <0x16>;
offset = <0x34>;
status = "disabled";
}

that must be wrong, it crashed in kernel booting.
I only added status = "disabled": https://github.com/optimeas/linux-tx6-5.10/blob/tx6-5.10/arch/arm/boot/dts/imx6dl-tx6s-8035-smartmini-v2p3.dts#L77

Best regards,
Matthias


Re: RTC issue

JH
 

Hello Matthias,

Thanks for your kind response.

I have seen the same message on an i.MX6S7
(https://www.karo-electronics.com/fileadmin/download/Datasheets/TX6S-Datasheet.pdf)
with kernel 5.10 (in a dunfell Yocto after I upgraded from kernel 4.14).

Since we use an external RTC on the I2C bus, I disabled the internal RTC
("snvs_rtc") in the device tree, and did not analyze the problem further.
How did you disable snvs_rtc? My device tree to include imx6ull.dtsi
which don't have snvs_rtc, only has snvs-rtc-lp, so I added status =
"disabled"; to the snvs-rtc-lp node:

snvs-rtc-lp {
compatible = "fsl,sec-v4.0-mon-rtc-lp";
regmap = <0x16>;
offset = <0x34>;
status = "disabled";
}

that must be wrong, it crashed in kernel booting.

[ 9.478754] ---[ end trace dc624b5857965e18 ]---
[ 9.483962] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0b
[ 9.483962]
[ 9.493223] ---[ end Kernel panic - not syncing: Attempted to kill init! exib
[ 9.493223] ]---


Thank you.

Kind regards,

- jupiter


Re: Hardknott support level

Randy MacLeod
 

On 2021-08-03 9:52 a.m., Alexander Kanavin wrote:
Hardknott will not become an LTS version, and will be maintained for 7 months, per https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS <https://urldefense.com/v3/__https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS__;!!AjveYdw8EvQ!NIoKnDSRFq3WDiKuTYy4hTbk0Nk0McU69nTZltOJaEobA7lVri6QJvk6HoQXH-Qq0S1rew$> (all of it worth reading).
The current plan is that Kirkstone will be the next LTS release (there's an LTS release every two years).
My recommendation is to start the project using current master (rather than something already released), periodically rebase on a later master, and branch off the stable/product branches in sync with upstream LTS releases. Rebasing from one yocto release to another yocto release is a lot more painful than rolling master + stable LTS model.
Alex
Or contact one of the companies that support Yocto:


https://www.yoctoproject.org/ecosystem/yocto-project-compatible-product-showcase/

That page is out of date and I'm trying to get it refreshed but it at
least shows which companies are available.

../Randy

On Tue, 3 Aug 2021 at 15:40, Fernando Luiz Cola <ferlzc@... <mailto:ferlzc@...>> wrote:
Hi, I'm starting a new project using Yocto and we plan to use Stable
(Hardknott - 3.3).
We gather this information on:
https://wiki.yoctoproject.org/wiki/Releases
<https://urldefense.com/v3/__https://wiki.yoctoproject.org/wiki/Releases__;!!AjveYdw8EvQ!NIoKnDSRFq3WDiKuTYy4hTbk0Nk0McU69nTZltOJaEobA7lVri6QJvk6HoQXH-TNnj1LJA$>
How can I verify/follow the when the project will schedule from
Stable to LTS?  There is an estimate for the EOL ?
Thank you in advance

--
# Randy MacLeod
# Wind River Linux


Re: multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

Executing

bitbake lib32-libtool-cross -e

Yields, among many others,

 

18513 # $TARGET_VENDOR [3 operations]

18514 #   set /home/build/tisdk/sources/oe-core/meta/conf/bitbake.conf:132

18515 #     "-oe"

18516 #   set /home/build/tisdk/sources/meta-arago/meta-arago-distro/conf/distro/include/toolchain-arm.inc:15

18517 #     ""

18518 #   override[virtclass-multilib-lib32]:set multilib_global.bbclass:159 [multilib_virtclass_handler_vendor]

18519 #     "mllib32"

18520 # pre-expansion value:

18521 #   "mllib32"

18522 TARGET_VENDOR="mllib32"

 

Later, HOST_VENDOR  = "${TARGET_VENDOR}",

And HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"

 

Ok.

 

So either these variables are calculated incorrectly, or the libtool-cross recipe needs to be fixed in order to support multilib properly.

 

Can anyone please assist?

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 5:03 PM
To: Geller, Nir <nir.geller@...>; yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

The variable SYS_HOST is expanded to armmllib32-linux-gnueabi

Shouldn’t it be expanded to arm-none-linux-gnueabihf ?

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 4:41 PM
To: yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Investigating run.do_configure suggests that in the configure stage oe_runconf() is set with what seems to be wrong –host and –target values:

 --host=armmllib32-linux-gnueabi   --target=armmllib32-linux-gnueabi

 

How can I influence oe_runconf() generation and set correct values?

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 12:42 PM
To: yocto@...
Subject: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 


Re: multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

The variable SYS_HOST is expanded to armmllib32-linux-gnueabi

Shouldn’t it be expanded to arm-none-linux-gnueabihf ?

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 4:41 PM
To: yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Investigating run.do_configure suggests that in the configure stage oe_runconf() is set with what seems to be wrong –host and –target values:

 --host=armmllib32-linux-gnueabi   --target=armmllib32-linux-gnueabi

 

How can I influence oe_runconf() generation and set correct values?

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 12:42 PM
To: yocto@...
Subject: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 


Re: multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

Investigating run.do_configure suggests that in the configure stage oe_runconf() is set with what seems to be wrong –host and –target values:

 --host=armmllib32-linux-gnueabi   --target=armmllib32-linux-gnueabi

 

How can I influence oe_runconf() generation and set correct values?

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 12:42 PM
To: yocto@...
Subject: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 


Re: #yocto debbuging option under zeus #yocto

Monsees, Steven C (US)
 

 

Is it documented anywhere on how one might manually load debug info an for image with the binaries stripped ?

 

Thanks,

Steve

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, August 10, 2021 1:48 PM
To: yocto@...
Subject: [yocto] #yocto debbuging option under zeus

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I ran across the following under the Yocto Project Profiling and Tracing Manual, and after checking my ipk data files/layout, I was wondering if someone could tell me, if ipk is capable of performing a similar set of operations to install my debug data ?, and if so, what would be the correct command sequence ?

 

“ The debug packages once built can be found in build/tmp/deploy/rpm/* on the host system. Find the busybox-dbg-...rpm file and copy it to the target. For example:

 

[trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2r2.core2_32.rpm root@....31:

     root@....31's password:

     busybox-dbg-1.20.2-r2.core2_32.rpm                     100% 1826KB   1.8MB/s   00:01

 

Now install the debug rpm on the target:

     root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm

 

Thanks,

Steve


multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 


Re: New Override Syntax

Richard Purdie
 

On Wed, 2021-08-11 at 10:18 +0200, Michael Opdenacker wrote:
Hi Richard,

On 8/10/21 10:21 PM, Richard Purdie wrote:
On Tue, 2021-08-10 at 17:51 +0000, Darcy Watkins wrote:
My apologies. I don't think I made my question clear. I am asking about the 
compatibility of old style override syntax moving forward (and new style syntax
in old versions).

So if I continue using the old style override syntax (to ensure sure 
compatibility for use with older Yocto versions), at what future Yocto/OE 
release do you expect that old style override syntax will become erroneous 
(as opposed to say triggering deprecation warnings, etc)?

Is support for the new style override syntax present in any existing 
Yocto/OpenEmbedded releases (in other words, has it been there for a while, 
but we are just now actively migrating to use it)? If so, how far back does it go?
The new syntax will work on the dunfell, gatesgarth, hardknott, master and new 
release branches going forward. That applies now and that support will be in the
next point releases for dunfell (3.1.11) and hardknott (3.3.3).

Thank you for the clarification.

Why do you mention Gatesgarth (3.2) while no update release is in sight?
According to https://wiki.yoctoproject.org/wiki/Releases, it's already
end of life.
I mention is as if I didn't someone would ask about it. I did backport the change
to the corresponding bitbake branch and it hence made it to the poky branch for
gatesgarth but there are no plans for any further 3.2 releases.

Cheers,

Richard


Re: New Override Syntax

Michael Opdenacker
 

Hi Richard,

On 8/10/21 10:21 PM, Richard Purdie wrote:
On Tue, 2021-08-10 at 17:51 +0000, Darcy Watkins wrote:
My apologies. I don't think I made my question clear. I am asking about the 
compatibility of old style override syntax moving forward (and new style syntax
in old versions).

So if I continue using the old style override syntax (to ensure sure 
compatibility for use with older Yocto versions), at what future Yocto/OE 
release do you expect that old style override syntax will become erroneous 
(as opposed to say triggering deprecation warnings, etc)?

Is support for the new style override syntax present in any existing 
Yocto/OpenEmbedded releases (in other words, has it been there for a while, 
but we are just now actively migrating to use it)? If so, how far back does it go?
The new syntax will work on the dunfell, gatesgarth, hardknott, master and new 
release branches going forward. That applies now and that support will be in the
next point releases for dunfell (3.1.11) and hardknott (3.3.3).

Thank you for the clarification.

Why do you mention Gatesgarth (3.2) while no update release is in sight?
According to https://wiki.yoctoproject.org/wiki/Releases, it's already
end of life.

Cheers,
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


[meta-zephyr][PATCH 1/2] zephyr-kernel-src: switch to main branch for hal_stm32 module repo

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 950966e..abe755d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -12,7 +12,7 @@ SRC_URI = "\
git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=${ZEPHYR_BRANCH};name=default \
git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
- git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
+ git://github.com/zephyrproject-rtos/hal_stm32.git;branch=main;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
git://github.com/zephyrproject-rtos/mbedtls.git;protocol=https;destsuffix=git/modules/lib/mbedtls;name=mbedtls \
git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
git://github.com/zephyrproject-rtos/openthread.git;protocol=https;branch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
--
2.17.1


[meta-zephyr][PATCH 2/2] zephyr-kernel-src-dev.inc: add dev recipe

Naveen Saini
 

It allow to build against latest main branch. User need
to have following config locally to use it.

PREFERRED_VERSION_zephyr-kernel = "dev"

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
.../zephyr-kernel/zephyr-kernel-src-dev.inc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-dev.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-dev.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-dev.inc
new file mode 100644
index 0000000..da2a5d5
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-dev.inc
@@ -0,0 +1,17 @@
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "72bb75a360ce05bfc94ff0fbecda2e2d094e3d84"
+SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
+SRCREV_nordic = "00fd2aa97a22ea1052d9dabe1b18ab396daab93a"
+SRCREV_stm32 = "4200321ef1cd27cacc37b0439389424156bb1267"
+SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
+SRCREV_openthread = "542b14a5bc5b38f29e2cab892c66da670a524b05"
+SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
+
+ZEPHYR_BRANCH = "main"
+PV = "2.6.0+git${SRCPV}"
+
+SRC_URI:append = " file://0001-cmake-add-yocto-toolchain.patch \
+ file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+ "
--
2.17.1


[ANNOUNCEMENT] Yocto Project 3.1.10 (dunfell-23.0.10) is Released

Vineela
 

Hello,

 

We are pleased to announce the Yocto Project 3.1.10 (dunfell-23.0.10) Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/poky-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/poky-dunfell-23.0.10.tar.bz2

 

A gpg signed version of the release notes is available at:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/testreport.txt

 

Thank you for everyone's contributions to this release.

 

Vineela Tummalapalli

Yocto Project Build and Release

vineela.tummalapalli@...

 

 

- --------------------------

yocto-3.1.10 Release Notes

- --------------------------

 

- --------------------------

Repositories/Downloads

- --------------------------

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: dunfell

Tag: yocto-3.1.10

Git Revision: 2a848e95074318f3a243df7b3f40513a13173a82

Release Artefact: poky-dunfell-23.0.10

sha: 8ff647b1de50cc915491765b6c19e9f1430519e7238275d7e012e0183a7c6f7d

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/poky-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/poky-dunfell-23.0.10.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: dunfell

Tag: 2020-04.10-dunfell

Git Revision: 9ae339ace9274be71bfd3b5e5da64dceac9fa963

Release Artefact: oecore-dunfell-23.0.10

sha: 651943e0919c6731441c67460b35b92f592bf60f9509b0be041cacdcb7db838c

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/oecore-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/oecore-dunfell-23.0.10.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: dunfell

Tag: yocto-3.1.10

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.10

sha: a2db888019c3e35cf12edda6fc68ae4f9522a2a975a57f492e9f86673dfa5c82

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/meta-mingw-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/meta-mingw-dunfell-23.0.10.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: dunfell

Tag: yocto-3.1.10

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.10

sha: 97e915d0312fd07a6da3ae0fd21c9463ddeae03bc097b3cfe75234a066bb7045

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/meta-gplv2-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/meta-gplv2-dunfell-23.0.10.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: 1.46

Tag: 2020-04.10-dunfell

Git Revision: 0e0af15b84e07e6763300dcd092b980086b9b9c4

Release Artefact: bitbake-dunfell-23.0.10

sha: 99fbb9ecf86385bf1effbde433f95d465c3ab90084b9dc985597220b60b6c0bd

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.10/bitbake-dunfell-23.0.10.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.10/bitbake-dunfell-23.0.10.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: dunfell

Tag: yocto-3.1.10

Git Revision:180d5fcb893e8b2ebcd779d1b07f5c9e8e1bceca

 

- --------------

Contributors

- --------------

Alexander Kanavin

Andrej Valek

Bruce Ashfield

Chen Qi

Denys Dmytriyenko

Florian Amstutz

Jain Sangeeta

Jasper Orschulko

Khem Raj

Marek Vasut

Michael Halstead

Michael Ho

Minjae Kim

Richard Purdie

Steve Sakoman

Tim Orling

Tomasz Dziendzielski

Yi Zhao

Zoltán Böszörményi

 

- ---------------

Known Issues

- ---------------

AB-INT PTEST: tcl socket.test intermittent failure

 

 

- ---------------

Security Fixes

- ---------------

gstreamer-plugins-good: ignore CVE-2021-3497/8 since they are fixed

gstreamer-plugins-base: ignore CVE-2021-3522 since it is fixed

bluez: fix CVE-2021-3588

dhcp: fix CVE-2021-25217

busybox: fix CVE-2021-28831

gstreamer-plugins-base: fix CVE-2021-3522

rpm: fix CVE-2021-3421

libx11: Fix CVE-2021-31535

libxml2: Fix CVE-2021-3518

expat: fix CVE-2013-0340

 

 

- ---------------

Fixes

- ---------------

bitbake: providers: replace newly added logger.warn() with logger.warning()

bitbake: data_smart: Allow colon in variable expansion regex

bitbake: data_smart/parse: Allow ':' characters in variable/function names

bitbake: BBHandler: Don't classify shell functions that names start with "python*" as python function

poky.conf: Bump version for 3.1.10 release

documentation: prepare for 3.1.10 release

kernel-devsrc: fix 32bit ARM devsrc builds

linux-yocto/5.4: update to v5.4.132

linux-yocto/5.4: update to v5.4.131

busybox: add tmpdir option into mktemp applet

sstate: Drop pseudo exclusion

pseudo: Update to latest version including statx fix

pseudo: Add uninative configuration sanity check

report-error: Drop pointless inherit

update-rc.d: update SRCREV to pull in fix for non-bash shell support

tzdata: Allow controlling zoneinfo binary format

oeqa/selftest/multiprocesslauch: Fix test race

dwarfsrcfiles: Avoid races over debug-link files

bootchart2: update 0.14.8 -> 0.14.9

glibc: update to lastest 2.31 release HEAD

webkitgtk: Upgrade to 2.28.4

webkitgtk: upgrade 2.28.2 -> 2.28.3

python3: upgrade 3.8.10 -> 3.8.11

oeqa/selftest/archiver: Allow tests to ignore empty directories

devtool: deploy-target: Fix preserving attributes when using --strip

sstate/staging: Handle directory creation race issue

oeqa/selftest/runcmd: Tweal test timeouts

sstate.bbclass: fix errors about read-only sstate mirrors

package_pkgdata: Avoid task hash mismatches for generic task changes

perf: Use python3targetconfig to ensure we use target libraries

selftest: do not hardcode /tmp/sdk

kernel-devicetree: Fix interaction when packaging disabled

kernel: Fix interaction when packaging disabled

linux-yocto/5.4: update to v5.4.129

linux-yocto/5.4: update to v5.4.128

linux-yocto/5.4: update to v5.4.125

linux-yocto/5.4: update to v5.4.124

python3: apply test skipping patch unconditionally

python3: skip tests requiring tools-sdk

python3-ptest: add newly discovered missing rdeps

python3: upgrade 3.8.9 -> 3.8.10

python3: upgrade 3.8.8 -> 3.8.9

powertop: fix aclocal error too many loops

python3: upgrade 3.8.7 -> 3.8.8

python3: upgrade 3.8.6 -> 3.8.7

python3: upgrade 3.8.5 -> 3.8.6

python3: upgrade 3.8.4 -> 3.8.5

python3: upgrade 3.8.3 -> 3.8.4

python3: upgrade 3.8.2 -> 3.8.3

uninative: Upgrade to 3.2 (gcc11 support)

3061 - 3080 of 57408