yocto@lists.yoctoproject.org

Re: #yocto debbuging option under zeus #yocto

Khem Raj

#54384

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

#54383

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

Show quoted text

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

#54382

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

Show quoted text

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

#54381

*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

#54380

What happens when you 'bitbake gdb'?

Alex

Show quoted text

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

#54379

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@...>

#54378

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

Cheers,

Jason.

Show quoted text

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

#54377

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

#54376

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

#54375

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.
AlexOr 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@...>

#54374

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.

Show quoted text

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

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@...>

#54373