Date   

Re: #sdk -Standard SDK build with cmake and meta-clang gives error when I attempt topull in compiler-rt #sdk

Monsees, Steven C (US)
 

 

I think there is a problem with compiler-rt component and cmake…

 

Doing bitbake compiler-rt produces:

 

Initialising tasks: 100% |#####################################################| Time: 0:00:00

NOTE: Executing SetScene Tasks

NOTE: Executing RunQueue Tasks

ERROR: compiler-rt-5.0.1+gitAUTOINC+4b38c4038a-r0 do_configure: Function failed: do_configure (log file is located at /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/log.do_configure.17534)

ERROR: Logfile of failure stored in: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/log.do_configure.17534

Log data follows:

| DEBUG: Executing shell function do_configure

| -- The C compiler identification is GNU 7.3.0

| -- The CXX compiler identification is GNU 7.3.0

| -- The ASM compiler identification is GNU

| -- Found assembler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc

| -- Check for working C compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc

| -- Check for working C compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc -- works

| -- Detecting C compiler ABI info

| -- Detecting C compiler ABI info - done

| -- Detecting C compile features

| -- Detecting C compile features - done

| -- Check for working CXX compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++

| -- Check for working CXX compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++ -- works

| -- Detecting CXX compiler ABI info

| -- Detecting CXX compiler ABI info - done

| -- Detecting CXX compile features

| -- Detecting CXX compile features - done

| -- Looking for unwind.h

| -- Looking for unwind.h - found

| CMake Error at CMakeLists.txt:38 (find_package):

|   By not providing "FindLLVM.cmake" in CMAKE_MODULE_PATH this project has

|   asked CMake to find a package configuration file provided by "LLVM", but

|   CMake did not find one.

|

|   Could not find a package configuration file provided by "LLVM" with any of

|   the following names:

|

|     LLVMConfig.cmake

|     llvm-config.cmake

|

|   Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set

|   "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"

|   provides a separate development package or SDK, be sure it has been

|   installed.

|

|

| -- Configuring incomplete, errors occurred!

| See also "/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/build/CMakeFiles/CMakeOutput.log".

| WARNING: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/run.do_configure.17534:1 exit 1 from 'cmake $oecmake_sitefile /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/git -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_BINDIR:PATH=bin -DCMAKE_INSTALL_SBINDIR:PATH=sbin -DCMAKE_INSTALL_LIBEXECDIR:PATH=libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/etc -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=../com -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=/var -DCMAKE_INSTALL_LIBDIR:PATH=lib -DCMAKE_INSTALL_INCLUDEDIR:PATH=include -DCMAKE_INSTALL_DATAROOTDIR:PATH=share -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_TOOLCHAIN_FILE=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/toolchain.cmake -DCMAKE_VERBOSE_MAKEFILE=1 -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 -DCOMPILER_RT_STANDALONE_BUILD=ON -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=x86_64-poky-linux -DCOMPILER_RT_BUILD_XRAY=OFF -G Ninja ${PACKAGECONFIG_CONFARGS} -Wno-dev'

| ERROR: Function failed: do_configure (log file is located at /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/corei7-64-poky-linux/compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/log.do_configure.17534)

ERROR: Task (/disk0/scratch/smonsees/yocto/workspace_2/poky/../meta-clang/recipes-devtools/clang/compiler-rt_git.bb:do_configure) failed with exit code '1'

NOTE: Tasks Summary: Attempted 495 tasks of which 488 didn't need to be rerun and 1 failed.

 

Summary: 1 task failed:

  /disk0/scratch/smonsees/yocto/workspace_2/poky/../meta-clang/recipes-devtools/clang/compiler-rt_git.bb:do_configure

 


Re: ABI Version for MIPS platform changed from 0 to 5

Khem Raj
 

On Mon, Aug 24, 2020 at 7:13 AM MikeB <mabnhdev@gmail.com> wrote:

Your solution worked great! Thank you for that as I don't think I would have tracked that down soon.

I now have a follow on problem that I have not been able to solve yet - mostly because my knowledge of the GNU toolchain is not very deep.

This problem only shows up in my Dunfell MIPS build - I also maintain x86_64, AARCH64, and ARM platforms.

I use the SDK to build some proprietary apps.

I have a library libcommon.so that contains many functions used by the proprietary apps.

I have an app that uses only a few of the functions in libcomon.so and none of those functions have any further dependencies.

When I try to link the app using the Dunfell MIPS SDK, it looks like the linker is including every function in libcommon.so into my app. Many of the unused functions have further dependencies on other libraries which I do not link in because this app isn't using any of those functions.

I've tried everything I can think of to fix this link failure, but no luck.

I assume I'm missing some linker flag now required in Dunfell, but I don't know which one.

Any thoughts on how to fix my linker failure?
which linker are you using by default, is it gold linker on other
platforms and bfd linker on mips ?
maybe you want to try --allow-shlib-undefined linker option.


Thanks, Mike


On Thu, Aug 20, 2020 at 8:04 PM Khem Raj <raj.khem@gmail.com> wrote:

On Wed, Aug 19, 2020 at 3:08 AM MikeB <mabnhdev@gmail.com> wrote:

Reposting in the hopes of getting an answer - I'm stuck.

I'm in the process of upgrading from Zeus to Dunfell. For my MIPS platform, the library ABI version has changed from 0 to 5. I have some backward compatibility issues that require generating at least some libraries with ABI version 0. I've tried using -fabi_version=0 in my CCFLAGS, but that seems to be ignored. Can someone tell me how to set the ABI version back to 0 in my image and SDK?

I'm building for a custom MIPs platform running on a Cavium Octeon II in 32-bit mode.

TUNE_FEATURES = "o32 bigendian fpu-hard octeon2"

A current Dunfell shared library ELF Header looks like this:

ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 05 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 5
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x1630
Start of program headers: 52 (bytes into file)
Start of section headers: 22488 (bytes into file)
Flags: 0x808d1107, noreorder, pic, cpic, 32bitmode, octeon2, o32, mips64r2

The same library built with Zeus looks like this.

ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x1500
Start of program headers: 52 (bytes into file)
Start of section headers: 22340 (bytes into file)
Flags: 0x808d1107, noreorder, pic, cpic, 32bitmode, octeon2, o32, mips64r2

The ABI Version being the issue.
This is due to switching default hash style from sysv to gnu starting
dunfell. You can switch back to sysv either via LDFLAGS
or explicitly define

LINKER_HASH_STYLE_mipsarch = "sysv"

in your distro.


Re: #sdk -Standard SDK build with cmake and meta-clang gives error when I attempt topull in compiler-rt #sdk

Khem Raj
 

On Mon, Aug 24, 2020 at 12:50 PM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am having trouble configuring my SDK to use the meta-clang compiler-rt component properly.



How do I configure my build so meta-clang brings in compiler-rt and generates the libclang_rt.binutils-x86_64.a library I require?



When I attempt to build in “compiler-rt” component I get the CMAKE Error shown below.



No matter how I try, for example:



TOOLCHAIN_TARGET_TASK_append = "compiler-rt-static-dev compiler-rt-dev"
this should bring the compiler-rt .a files into target sysroot


Or:



SDK_EXTRA_TOOLS = " \

nativesdk-cmake \

nativesdk-clang \

nativesdk-compiler-rt \
nativesdk compile-rt may not be needed.


"

I get the "cmake" error described below.



(1) What Is this the correct method to add this components to my SDK ?

(2) I do not understand how to resolve this , all are yocto based components, the only llvm components are pulled in by meta-clang, what am I expected to edit to resolve ?, and how ? Can someone explain to me what this error is attempting to convey, and what I am doing wrong ?

(3) Is it correct to expect the cmake and clang components to work together under yocto?

(4) I do not want the tools built into my kernel just the SDK for development, Is there better way to do what I want to do here ?



Note: My target and host systems are both x86-64…



And, yes, the "-rtlib-libgcc" works for my basic test code and bypasses requiring compiler-rt, but I would like to understand what is going on below and be able to build correctly...



Synopsis of issue:

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



When I build my SDK, I setup the following:



SDKMACHINE = "x86_64"

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

SDK_EXTRA_TOOLS = " \

nativesdk-cmake \

nativesdk-clang \

"

require conf/distro/include/yocto-uninative.inc

INHERIT += "uninative"



My SDK builds and installs without issue…



Running a very basic example produces the following issue:



09:22 smonsees@yix490016 ~/yocto/test>make hello x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux -O2 -pipe -g -feliminate-unused-debug-types -ansi -c hello.c x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux -O2 -pipe -g -feliminate-unused-debug-types -ansi hello.o -o hello

clang-5.0: warning: argument unused during compilation: '-ansi' [-Wunused-command-line-argument]

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld: cannot find /disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/clang/5.0.1/lib/linux/libclang_rt.builtins-x86_64.a: No such file or directory

clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)

make: *** [hello] Error 1
this tells me that somehow compiler-rt-static-dev is not included or
is missing this libclang_rt.builtins-x86_64.a


09:22 smonsees@yix490016 ~/yocto/test>



The file in question does not exist on my system.



If I add "nativesdk-compiler-rt" like so:



SDK_EXTRA_TOOLS = " \

nativesdk-cmake \

nativesdk-clang \

nativesdk-compiler-rt \

"



I get the following error:



Log data follows:

| DEBUG: Executing shell function do_configure

| -- The C compiler identification is GNU 7.3.0

| -- The CXX compiler identification is GNU 7.3.0

| -- The ASM compiler identification is GNU

| -- Found assembler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-gcc

| -- Check for working C compiler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-gcc

| -- Check for working C compiler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-gcc -- works

| -- Detecting C compiler ABI info

| -- Detecting C compiler ABI info - done

| -- Detecting C compile features

| -- Detecting C compile features - done

| -- Check for working CXX compiler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-g++

| -- Check for working CXX compiler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-g++ -- works

| -- Detecting CXX compiler ABI info

| -- Detecting CXX compiler ABI info - done

| -- Detecting CXX compile features

| -- Detecting CXX compile features - done

| -- Looking for unwind.h

| -- Looking for unwind.h - found

| CMake Error at CMakeLists.txt:38 (find_package):

| By not providing "FindLLVM.cmake" in CMAKE_MODULE_PATH this project has

| asked CMake to find a package configuration file provided by "LLVM", but

| CMake did not find one.

|

| Could not find a package configuration file provided by "LLVM" with any of

| the following names:

|

| LLVMConfig.cmake

| llvm-config.cmake

|

| Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set

| "LLVM_DIR" to a directory containing one of the above files. If "LLVM"

| provides a separate development package or SDK, be sure it has been

| installed.

|

|

| -- Configuring incomplete, errors occurred!

| See also "/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/build/CMakeFiles/CMakeOutput.log".

| WARNING: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/run.do_configure.25988:1 exit 1 from 'cmake $oecmake_sitefile /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/git -DCMAKE_INSTALL_PREFIX:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/usr -DCMAKE_INSTALL_BINDIR:PATH=bin -DCMAKE_INSTALL_SBINDIR:PATH=bin -DCMAKE_INSTALL_LIBEXECDIR:PATH=libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/etc -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=../com -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/var -DCMAKE_INSTALL_LIBDIR:PATH=lib -DCMAKE_INSTALL_INCLUDEDIR:PATH=include -DCMAKE_INSTALL_DATAROOTDIR:PATH=share -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_TOOLCHAIN_FILE=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/toolchain.cmake -DCMAKE_VERBOSE_MAKEFILE=1 -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 -DCOMPILER_RT_STANDALONE_BUILD=ON -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=x86_64-pokysdk-linux -DCOMPILER_RT_BUILD_XRAY=OFF -G Ninja ${PACKAGECONFIG_CONFARGS} -DLLVM_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/llvm-tblgen -DCLANG_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/clang-tblgen -Wno-dev'

| ERROR: Function failed: do_configure (log file is located at

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/log.do_configure.25988)

ERROR: Task (virtual:nativesdk:/disk0/scratch/smonsees/yocto/workspace_2/poky/../meta-clang/recipes-devtools/clang/compiler-rt_git.bb:do_configure) failed with exit code '1'

NOTE: Tasks Summary: Attempted 5382 tasks of which 5341 didn't need to be rerun and 1 failed.



Thanks,

Steve






M+ & H bugs with Milestone Movements WW34

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW34 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

6437

Document how to set up the Yocto Project for production work

randy.macleod@...

mark.morton@...

3.2 M2

3.2 M3

 

12937

Consistent naming scheme for deployed artifacts

richard.purdie@...

Martin.Jansa@...

3.2 M2

3.3 M1

 

13023

Switch to memory resident bitbake by default in 3.3

richard.purdie@...

unassigned@...

3.2 M3

3.3 M1

 

13071

Multiconfig builds may try to execute events that don't exist for them

randy.macleod@...

alejandro@...

3.2 M2

3.2 M3

 

13374

Determine 32bit guest support on arm64

randy.macleod@...

jon.mason@...

3.2 M2

3.2 M3

 

13426

Loses track of data if file rename()d to same name

randy.macleod@...

joe.slater@...

3.2 M2

3.2 M3

 

13533

Devtool finish on _git package with SRCPV in PV points to wrong WORKDIR

randy.macleod@...

jaewon@...

3.2 M2

3.2 M3

 

13550

username/password specified to gitsm:// does not get propagated to submodules

richard.purdie@...

mark.hatle@...

3.2 M2

3.2 M3

 

13566

Write tests for multiconfig files in layers and document

richard.purdie@...

mostthingsweb@...

3.2 M2

3.2 M3

 

13581

Line wrapping over prompt in BASH

randy.macleod@...

jason.wessel@...

3.2 M2

3.2 M3

 

13589

Document sstate cache mirror best practices

randy.macleod@...

mark.morton@...

3.2 M2

3.2 M3

 

13722

Debugging With the GNU Project Debugger enhancements

richard.purdie@...

rpjday@...

3.2 M2

3.2 M3

 

13731

Cross canadian GCC fails to find header files when using tclibc-newlib

randy.macleod@...

alejandro@...

3.2 M2

3.2 M3

 

13742

HashEquiv server should have a read-only port or endpoint

richard.purdie@...

dl9pf@...

3.2 M2

3.2 M3

 

13767

Creating PDF docs doesn't include image files

randy.macleod@...

mark.morton@...

3.2 M2

3.2 M3

 

13788

zeus-nut] selftest failure PackageTests.test_gdb_hardlink

randy.macleod@...

randy.macleod@...

3.0.4

3.0.5

 

13808

do_task[noexec] = "" marks task noexec, which is inconsistent with docs

randy.macleod@...

mostthingsweb@...

3.2 M2

3.2 M3

 

13822

Easy to have misleading warnings if env script is executed instead of sourced

randy.macleod@...

ankur.tyagi85@...

3.2 M2

3.2 M3

 

13884

Numerous references to deprecated "distro_features_check" still in reference manual

randy.macleod@...

rpjday@...

3.2 M2

3.2 M3

 

13901

npm build error when the shrinkwrap file has no dependencies

randy.macleod@...

jeanmarie.lemetayer@...

3.2 M2

3.2 M3

 

13903

npmsw fetcher fails if multiple recipes have common npm packages

randy.macleod@...

jeanmarie.lemetayer@...

3.2 M2

3.2 M3

 

13906

[QA 3.0.3 RC2] failure in ptest: valgrind.helgrind/tests/tc19_shadowmem

randy.macleod@...

anuj.mittal@...

3.0.4

3.0.5

 

13907

[QA 3.0.3 RC2] failure in ptest: zlib.zlib

randy.macleod@...

anuj.mittal@...

3.0.4

3.0.5

 

13937

llvm-config does not work any more with multilib

randy.macleod@...

ydirson@...

3.2 M2

3.2 M3

 

13938

devtool modify virtual/kernel fails when EXTRAVERSION field is empty in Makefile

richard.purdie@...

timothy.t.orling@...

3.2 M2

3.2 M3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW33!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

jon.mason@...

2

richard.purdie@...

2

akuster808@...

1

raj.khem@...

1

matthew.zeng@...

1

steve@...

1

michael@...

1

anuj.mittal@...

1

Grand Total

10

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.2

Stephen Jolley
 

All,

Below is the list as of top 46 bug owners as of the end of WW34 of who have open medium or higher bugs and enhancements against YP 3.2.   There are 47 possible work days left until the final release candidates for YP 3.2 needs to be released.

Who

Count

richard.purdie@...

29

david.reyna@...

22

bruce.ashfield@...

18

akuster808@...

17

bluelightning@...

17

ross@...

10

mark.morton@...

10

kai.kang@...

9

randy.macleod@...

9

Qi.Chen@...

9

JPEWhacker@...

9

timothy.t.orling@...

9

sakib.sajal@...

7

trevor.gamblin@...

7

raj.khem@...

6

hongxu.jia@...

5

rpjday@...

4

joe.slater@...

4

mingli.yu@...

4

jon.mason@...

3

yi.zhao@...

3

ydirson@...

3

mostthingsweb@...

3

jpuhlman@...

2

akuster@...

2

chee.yang.lee@...

2

kergoth@...

2

michael@...

2

jeanmarie.lemetayer@...

2

mark.hatle@...

2

alejandro@...

2

jaewon@...

2

changqing.li@...

1

khairul.rohaizzat.jamaluddin@...

1

amber.n.elliot@...

1

maxime.roussinbelanger@...

1

aehs29@...

1

ankur.tyagi85@...

1

steve@...

1

dl9pf@...

1

matt.ranostay@...

1

jason.wessel@...

1

matthewzmd@...

1

liu.ming50@...

1

anuj.mittal@...

1

kai.ruhnau@...

1

Grand Total

249

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 339 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


#sdk -Standard SDK build with cmake and meta-clang gives error when I attempt topull in compiler-rt #sdk

Monsees, Steven C (US)
 

 

I am having trouble configuring my SDK to use the meta-clang compiler-rt component properly.

 

How do I configure my build so meta-clang brings in compiler-rt and generates the libclang_rt.binutils-x86_64.a library I require?

 

When I attempt to build in “compiler-rt” component I get the CMAKE Error shown below.

 

No matter how I try, for example:

 

TOOLCHAIN_TARGET_TASK_append = "compiler-rt-static-dev compiler-rt-dev"

 

Or:

 

SDK_EXTRA_TOOLS = "  \

    nativesdk-cmake \

    nativesdk-clang \

    nativesdk-compiler-rt \

    "

I get the "cmake" error described below.

 

(1) What Is this the correct method to add this components to my SDK ?

(2) I do not understand how to resolve this , all are yocto based components, the only llvm components are pulled in by meta-clang, what am I expected to edit to resolve ?, and how ? Can someone explain to me what this error is attempting to convey, and what I am doing wrong ?

(3) Is it correct to expect the cmake and clang components to work together under yocto?

(4) I do not want the tools built into my kernel just the SDK for development, Is there better way to do what I want to do here ?

 

Note: My target and host systems are both x86-64…

 

And, yes, the "-rtlib-libgcc" works for my basic test code and bypasses requiring compiler-rt, but I would like to understand what is going on below and be able to build correctly...

 

Synopsis of issue:

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

 

When I build my SDK, I setup the following:

 

SDKMACHINE = "x86_64"

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

SDK_EXTRA_TOOLS = "  \

    nativesdk-cmake \

    nativesdk-clang \

    "

require conf/distro/include/yocto-uninative.inc

INHERIT += "uninative"

 

My SDK builds and installs without issue…

 

Running  a very basic example produces the following issue:

 

09:22 smonsees@yix490016 ~/yocto/test>make hello x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux  -O2 -pipe -g -feliminate-unused-debug-types  -ansi -c hello.c x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux  -O2 -pipe -g -feliminate-unused-debug-types  -ansi hello.o -o hello

clang-5.0: warning: argument unused during compilation: '-ansi' [-Wunused-command-line-argument]

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld: cannot find /disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/clang/5.0.1/lib/linux/libclang_rt.builtins-x86_64.a: No such file or directory

clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)

make: *** [hello] Error 1

09:22 smonsees@yix490016 ~/yocto/test>

 

The file in question does not exist on my system.

 

If I add "nativesdk-compiler-rt" like so:

 

SDK_EXTRA_TOOLS = "  \

    nativesdk-cmake \

    nativesdk-clang \

    nativesdk-compiler-rt \

    "

 

I get the following error:

 

Log data follows:

| DEBUG: Executing shell function do_configure

| -- The C compiler identification is GNU 7.3.0

| -- The CXX compiler identification is GNU 7.3.0

| -- The ASM compiler identification is GNU

| -- Found assembler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-gcc

| -- Check for working C compiler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-gcc

| -- Check for working C compiler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-gcc -- works

| -- Detecting C compiler ABI info

| -- Detecting C compiler ABI info - done

| -- Detecting C compile features

| -- Detecting C compile features - done

| -- Check for working CXX compiler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-g++

| -- Check for working CXX compiler:

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_6

| 4-pokysdk-linux/x86_64-pokysdk-linux-g++ -- works

| -- Detecting CXX compiler ABI info

| -- Detecting CXX compiler ABI info - done

| -- Detecting CXX compile features

| -- Detecting CXX compile features - done

| -- Looking for unwind.h

| -- Looking for unwind.h - found

| CMake Error at CMakeLists.txt:38 (find_package):

|   By not providing "FindLLVM.cmake" in CMAKE_MODULE_PATH this project has

|   asked CMake to find a package configuration file provided by "LLVM", but

|   CMake did not find one.

|

|   Could not find a package configuration file provided by "LLVM" with any of

|   the following names:

|

|     LLVMConfig.cmake

|     llvm-config.cmake

|

|   Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set

|   "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"

|   provides a separate development package or SDK, be sure it has been

|   installed.

|

|

| -- Configuring incomplete, errors occurred!

| See also "/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/build/CMakeFiles/CMakeOutput.log".

| WARNING: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/run.do_configure.25988:1 exit 1 from 'cmake $oecmake_sitefile /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/git -DCMAKE_INSTALL_PREFIX:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/usr -DCMAKE_INSTALL_BINDIR:PATH=bin -DCMAKE_INSTALL_SBINDIR:PATH=bin -DCMAKE_INSTALL_LIBEXECDIR:PATH=libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/etc -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=../com -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/var -DCMAKE_INSTALL_LIBDIR:PATH=lib -DCMAKE_INSTALL_INCLUDEDIR:PATH=include -DCMAKE_INSTALL_DATAROOTDIR:PATH=share -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_TOOLCHAIN_FILE=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/toolchain.cmake -DCMAKE_VERBOSE_MAKEFILE=1 -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 -DCOMPILER_RT_STANDALONE_BUILD=ON -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=x86_64-pokysdk-linux -DCOMPILER_RT_BUILD_XRAY=OFF -G Ninja ${PACKAGECONFIG_CONFARGS} -DLLVM_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/llvm-tblgen -DCLANG_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/clang-tblgen -Wno-dev'

| ERROR: Function failed: do_configure (log file is located at

| /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/s

| bcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler

| -rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/log.do_configure.25988)

ERROR: Task (virtual:nativesdk:/disk0/scratch/smonsees/yocto/workspace_2/poky/../meta-clang/recipes-devtools/clang/compiler-rt_git.bb:do_configure) failed with exit code '1'

NOTE: Tasks Summary: Attempted 5382 tasks of which 5341 didn't need to be rerun and 1 failed.

 

Thanks,

Steve

 

 


[meta-security][dunfel][PATCH] trousers: Several Security fixes

Armin Kuster
 

From: Armin Kuster <akuster@mvista.com>

Source: meta-security
MR: 105088
Type: Security Fix
Disposition: Backport from http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=787ba6faeaa8823a4d87e5edd15581cb4e12fa70
ChangeID: b55bccb002b9eb2c49dfe380406e2597bb1ade90
Description:

Fixes:
CVE-2020-24332
CVE-2020-24330
CVE-2020-24331

Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
(cherry picked from commit 787ba6faeaa8823a4d87e5edd15581cb4e12fa70)
Signed-off-by: Armin Kuster <akuster@mvista.com>
---
...-security-issues-that-are-present-if.patch | 94 +++++++++++++++++++
meta-tpm/recipes-tpm/trousers/trousers_git.bb | 1 +
2 files changed, 95 insertions(+)
create mode 100644 meta-tpm/recipes-tpm/trousers/files/0001-Correct-multiple-security-issues-that-are-present-if.patch

diff --git a/meta-tpm/recipes-tpm/trousers/files/0001-Correct-multiple-security-issues-that-are-present-if.patch b/meta-tpm/recipes-tpm/trousers/files/0001-Correct-multiple-security-issues-that-are-present-if.patch
new file mode 100644
index 0000000..72c81d1
--- /dev/null
+++ b/meta-tpm/recipes-tpm/trousers/files/0001-Correct-multiple-security-issues-that-are-present-if.patch
@@ -0,0 +1,94 @@
+From e74dd1d96753b0538192143adf58d04fcd3b242b Mon Sep 17 00:00:00 2001
+From: Matthias Gerstner <mgerstner@suse.de>
+Date: Fri, 14 Aug 2020 22:14:36 -0700
+Subject: [PATCH] Correct multiple security issues that are present if the tcsd
+ is started by root instead of the tss user.
+
+Patch fixes the following 3 CVEs:
+
+CVE-2020-24332
+If the tcsd daemon is started with root privileges,
+the creation of the system.data file is prone to symlink attacks
+
+CVE-2020-24330
+If the tcsd daemon is started with root privileges,
+it fails to drop the root gid after it is no longer needed
+
+CVE-2020-24331
+If the tcsd daemon is started with root privileges,
+the tss user has read and write access to the /etc/tcsd.conf file
+
+Authored-by: Matthias Gerstner <mgerstner@suse.de>
+Signed-off-by: Debora Velarde Babb <debora@linux.ibm.com>
+
+Upstream-Status: Backport
+CVE: CVE-2020-24332
+CVE: CVE-2020-24330
+CVE: CVE-2020-24331
+
+Signed-off-by: Armin Kuster <akuster@mvista.com>
+
+---
+ src/tcs/ps/tcsps.c | 2 +-
+ src/tcsd/svrside.c | 1 +
+ src/tcsd/tcsd_conf.c | 10 +++++-----
+ 3 files changed, 7 insertions(+), 6 deletions(-)
+
+Index: git/src/tcs/ps/tcsps.c
+===================================================================
+--- git.orig/src/tcs/ps/tcsps.c
++++ git/src/tcs/ps/tcsps.c
+@@ -72,7 +72,7 @@ get_file()
+ }
+
+ /* open and lock the file */
+- system_ps_fd = open(tcsd_options.system_ps_file, O_CREAT|O_RDWR, 0600);
++ system_ps_fd = open(tcsd_options.system_ps_file, O_CREAT|O_RDWR|O_NOFOLLOW, 0600);
+ if (system_ps_fd < 0) {
+ LogError("system PS: open() of %s failed: %s",
+ tcsd_options.system_ps_file, strerror(errno));
+Index: git/src/tcsd/svrside.c
+===================================================================
+--- git.orig/src/tcsd/svrside.c
++++ git/src/tcsd/svrside.c
+@@ -473,6 +473,7 @@ main(int argc, char **argv)
+ }
+ return TCSERR(TSS_E_INTERNAL_ERROR);
+ }
++ setgid(pwd->pw_gid);
+ setuid(pwd->pw_uid);
+ #endif
+ #endif
+Index: git/src/tcsd/tcsd_conf.c
+===================================================================
+--- git.orig/src/tcsd/tcsd_conf.c
++++ git/src/tcsd/tcsd_conf.c
+@@ -743,7 +743,7 @@ conf_file_init(struct tcsd_config *conf)
+ #ifndef SOLARIS
+ struct group *grp;
+ struct passwd *pw;
+- mode_t mode = (S_IRUSR|S_IWUSR);
++ mode_t mode = (S_IRUSR|S_IWUSR|S_IRGRP);
+ #endif /* SOLARIS */
+ TSS_RESULT result;
+
+@@ -798,15 +798,15 @@ conf_file_init(struct tcsd_config *conf)
+ }
+
+ /* make sure user/group TSS owns the conf file */
+- if (pw->pw_uid != stat_buf.st_uid || grp->gr_gid != stat_buf.st_gid) {
++ if (stat_buf.st_uid != 0 || grp->gr_gid != stat_buf.st_gid) {
+ LogError("TCSD config file (%s) must be user/group %s/%s", tcsd_config_file,
+- TSS_USER_NAME, TSS_GROUP_NAME);
++ "root", TSS_GROUP_NAME);
+ return TCSERR(TSS_E_INTERNAL_ERROR);
+ }
+
+- /* make sure only the tss user can manipulate the config file */
++ /* make sure only the tss user can read (but not manipulate) the config file */
+ if (((stat_buf.st_mode & 0777) ^ mode) != 0) {
+- LogError("TCSD config file (%s) must be mode 0600", tcsd_config_file);
++ LogError("TCSD config file (%s) must be mode 0640", tcsd_config_file);
+ return TCSERR(TSS_E_INTERNAL_ERROR);
+ }
+ #endif /* SOLARIS */
diff --git a/meta-tpm/recipes-tpm/trousers/trousers_git.bb b/meta-tpm/recipes-tpm/trousers/trousers_git.bb
index fe8f557..95e821b 100644
--- a/meta-tpm/recipes-tpm/trousers/trousers_git.bb
+++ b/meta-tpm/recipes-tpm/trousers/trousers_git.bb
@@ -16,6 +16,7 @@ SRC_URI = " \
file://tcsd.service \
file://get-user-ps-path-use-POSIX-getpwent-instead-of-getpwe.patch \
file://0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch \
+ file://0001-Correct-multiple-security-issues-that-are-present-if.patch \
"

S = "${WORKDIR}/git"
--
2.17.1


Re: Additional log handler

Konrad Weihmann
 

Thanks to both of you - seems like I missed out on BB_LOGCONFIG, but it's exactly what I was looking for.
Regards
Konrad

On 24.08.20 15:59, Joshua Watt wrote:
On 8/24/20 8:26 AM, Richard Purdie wrote:
On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote:
The newer log handling uses Python's structure logging configuration
[1], so you should be able to use whatever capabilities it has
(including logging different domains/levels to a separate file). In
fact, this is the only way logging is handled by core bitbake now;
all of the other logging mechanisms used by the UI are additional
configuration specified on top of the user's BB_LOGCONFIG file. If
you are interested, you can see this in bitbake/lib/bb/ui/knotty.py.
In that file is an additional tool that might be helpful. Around line
553, there are two commented lines of code:

     #import logging_tree
     #logging_tree.printout()

uncommenting them and installing the logging_tree python package will
make bitbake dump the entire structured logging configuration to
stdout on startup so you can look at it.
On a slightly different but related note, could we remove the
debug_domains code now? I assume that can all be handled by
BB_LOGCONFIG?
Ah, right; you jogged my memory :) Structured logging still co-exists with the debug_domains, so it's not the *only* way the core speicfies logging messages. The main reason for this is that we still need to pass the set of active logging domains to the bitbake workers that they only send back requested logging levels over IPC instead of all log levels (per some code I believe you wrote Richard). It should the theoretically possible to send over the entire structured log config (which isn't very large) to the worker and add in worker side handlers to send back logs over IPC instead of the simplified list of logging domains (as a bonus, this should allow you to log anything on the worker, not just things in the "BitBake" domain). IIRC I tried to get this working in the original change, but it ended up being more complicated and not strictly necessary for the feature at hand (extra logging hashequiv on the AB) so I left in the debug_domain method of filtering in the workers. Since I had to leave that in, I also left in the UI code to directly deal with the debug domains. The log handling itself still all goes through Python logging, and it correctly merges the structured logging and user domains so that the actual logging domain level filter level passed to the workers is the lower of the user specified logging domain and whatever is specified for that domain in the structured config. The UI code could fairly easily be converted to instead map the command line arguments to structured logging configuration, which would remove any knowledge of them on the UI side.
TL;DR No, we can't remove it yet, but we could with some work.


Cheers,

Richard


Re: Yocto standard SDK/cmake/ and meta-clang build issue

Mikko Rapeli
 

Hi,

On Mon, Aug 24, 2020 at 02:38:54PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

I am having trouble with configuring my SDK for meta-clang...

When I build my SDK, I setup the following:

SDKMACHINE = "x86_64"
SDKIMAGE_FEATURES_append = " staticdev-pkgs"
TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"
SDK_EXTRA_TOOLS = " \
nativesdk-cmake \
nativesdk-clang \
I was wondering on same thing few days ago.

nativesdk-clang and clang-cross-canadian-aarch64 if your target arch is aarch64
bring a working clang compiler to the SDK.

I was also missing the clang-cross bit for a long time and scratching my
head.

Hope this helps,

-Mikko


Yocto standard SDK/cmake/ and meta-clang build issue

Monsees, Steven C (US)
 

 

I am having trouble with configuring my SDK for meta-clang…

 

When I build my SDK, I setup the following:

 

SDKMACHINE = "x86_64"

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

SDK_EXTRA_TOOLS = "  \

    nativesdk-cmake \

    nativesdk-clang \

    "

require conf/distro/include/yocto-uninative.inc

INHERIT += "uninative"

 

(1)    Is this the correct method to add these components to my SDK ?

 

My SDK builds and installs without issue…

 

Running  a very basic example produces the following issue:

 

09:22 smonsees@yix490016 ~/yocto/test>make hello

x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux  -O2 -pipe -g -feliminate-unused-debug-types  -ansi -c hello.c

x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux  -O2 -pipe -g -feliminate-unused-debug-types  -ansi hello.o -o hello

clang-5.0: warning: argument unused during compilation: '-ansi' [-Wunused-command-line-argument]

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld: cannot find /disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/clang/5.0.1/lib/linux/libclang_rt.builtins-x86_64.a: No such file or directory

clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)

make: *** [hello] Error 1

09:22 smonsees@yix490016 ~/yocto/test>

 

The file in question does not exist on my system.

 

If I add "nativesdk-compiler-rt" like so:

 

SDK_EXTRA_TOOLS = "  \

    nativesdk-cmake \

    nativesdk-clang \

    nativesdk-compiler-rt \

    "

 

I get the following error:

 

Log data follows:

| DEBUG: Executing shell function do_configure

| -- The C compiler identification is GNU 7.3.0

| -- The CXX compiler identification is GNU 7.3.0

| -- The ASM compiler identification is GNU

| -- Found assembler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-gcc

| -- Check for working C compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-gcc

| -- Check for working C compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-gcc -- works

| -- Detecting C compiler ABI info

| -- Detecting C compiler ABI info - done

| -- Detecting C compile features

| -- Detecting C compile features - done

| -- Check for working CXX compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-g++

| -- Check for working CXX compiler: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-g++ -- works

| -- Detecting CXX compiler ABI info

| -- Detecting CXX compiler ABI info - done

| -- Detecting CXX compile features

| -- Detecting CXX compile features - done

| -- Looking for unwind.h

| -- Looking for unwind.h - found

| CMake Error at CMakeLists.txt:38 (find_package):

|   By not providing "FindLLVM.cmake" in CMAKE_MODULE_PATH this project has

|   asked CMake to find a package configuration file provided by "LLVM", but

|   CMake did not find one.

|

|   Could not find a package configuration file provided by "LLVM" with any of

|   the following names:

|

|     LLVMConfig.cmake

|     llvm-config.cmake

|

|   Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set

|   "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"

|   provides a separate development package or SDK, be sure it has been

|   installed.

|

|

| -- Configuring incomplete, errors occurred!

| See also "/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/build/CMakeFiles/CMakeOutput.log".

| WARNING: /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/run.do_configure.25988:1 exit 1 from 'cmake $oecmake_sitefile /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/git -DCMAKE_INSTALL_PREFIX:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/usr -DCMAKE_INSTALL_BINDIR:PATH=bin -DCMAKE_INSTALL_SBINDIR:PATH=bin -DCMAKE_INSTALL_LIBEXECDIR:PATH=libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/etc -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=../com -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=/opt/limws/2.4.1/sysroots/x86_64-pokysdk-linux/var -DCMAKE_INSTALL_LIBDIR:PATH=lib -DCMAKE_INSTALL_INCLUDEDIR:PATH=include -DCMAKE_INSTALL_DATAROOTDIR:PATH=share -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_TOOLCHAIN_FILE=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/toolchain.cmake -DCMAKE_VERBOSE_MAKEFILE=1 -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 -DCOMPILER_RT_STANDALONE_BUILD=ON -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=x86_64-pokysdk-linux -DCOMPILER_RT_BUILD_XRAY=OFF -G Ninja ${PACKAGECONFIG_CONFARGS} -DLLVM_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/llvm-tblgen -DCLANG_TABLEGEN=/disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/recipe-sysroot-native/usr/bin/clang-tblgen -Wno-dev'

| ERROR: Function failed: do_configure (log file is located at /disk0/scratch/smonsees/yocto/workspace_2/meta-bae/meta-limws/builds/sbcb-default/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-compiler-rt/5.0.1+gitAUTOINC+4b38c4038a-r0/temp/log.do_configure.25988)

ERROR: Task (virtual:nativesdk:/disk0/scratch/smonsees/yocto/workspace_2/poky/../meta-clang/recipes-devtools/clang/compiler-rt_git.bb:do_configure) failed with exit code '1'

NOTE: Tasks Summary: Attempted 5382 tasks of which 5341 didn't need to be rerun and 1 failed.

 

(2)    I do not understand how to resolve this , all are yocto based components, the only llvm components are pulled in by meta-clang, what am I expected to edit to resolve ?, and how ? Can someone explain to me what this error is attempting to convey, and what I am doing wrong ?

(3)    Is it correct to expect the cmake and clang components to work together under yocto?

(4)    I do not want the tools built into my kernel just the SDK for development, Is there better way to do what I want to do here ?

 

Thanks,

Steve

 


Re: ABI Version for MIPS platform changed from 0 to 5

MikeB
 

Your solution worked great!  Thank you for that as I don't think I would have tracked that down soon.

I now have a follow on problem that I have not been able to solve yet - mostly because my knowledge of the GNU toolchain is not very deep.

This problem only shows up in my Dunfell MIPS build - I also maintain x86_64, AARCH64, and ARM platforms.

I use the SDK to build some proprietary apps.

I have a library libcommon.so that contains many functions used by the proprietary apps.

I have an app that uses only a few of the functions in libcomon.so and none of those functions have any further dependencies.

When I try to link the app using the Dunfell MIPS SDK, it looks like the linker is including every function in libcommon.so into my app.  Many of the unused functions have further dependencies on other libraries which I do not link in because this app isn't using any of those functions.

I've tried everything I can think of to fix this link failure, but no luck.

I assume I'm missing some linker flag now required in Dunfell, but I don't know which one.

Any thoughts on how to fix my linker failure?

Thanks, Mike


On Thu, Aug 20, 2020 at 8:04 PM Khem Raj <raj.khem@...> wrote:
On Wed, Aug 19, 2020 at 3:08 AM MikeB <mabnhdev@...> wrote:
>
> Reposting in the hopes of getting an answer - I'm stuck.
>
> I'm in the process of upgrading from Zeus to Dunfell.  For my MIPS platform, the library ABI version has changed from 0 to 5.  I have some backward compatibility issues that require generating at least some libraries with ABI version 0.  I've tried using -fabi_version=0 in my CCFLAGS, but that seems to be ignored.  Can someone tell me how to set the ABI version back to 0 in my image and SDK?
>
> I'm building for a custom MIPs platform running on a Cavium Octeon II in 32-bit mode.
>
> TUNE_FEATURES  = "o32 bigendian fpu-hard octeon2"
>
> A current Dunfell shared library ELF Header looks like this:
>
> ELF Header:
>   Magic:   7f 45 4c 46 01 02 01 00 05 00 00 00 00 00 00 00
>   Class:                             ELF32
>   Data:                              2's complement, big endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       5
>   Type:                              DYN (Shared object file)
>   Machine:                           MIPS R3000
>   Version:                           0x1
>   Entry point address:               0x1630
>   Start of program headers:          52 (bytes into file)
>   Start of section headers:          22488 (bytes into file)
>   Flags:                             0x808d1107, noreorder, pic, cpic, 32bitmode, octeon2, o32, mips64r2
>
> The same library built with Zeus looks like this.
>
> ELF Header:
>   Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
>   Class:                             ELF32
>   Data:                              2's complement, big endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              DYN (Shared object file)
>   Machine:                           MIPS R3000
>   Version:                           0x1
>   Entry point address:               0x1500
>   Start of program headers:          52 (bytes into file)
>   Start of section headers:          22340 (bytes into file)
>   Flags:                             0x808d1107, noreorder, pic, cpic, 32bitmode, octeon2, o32, mips64r2
>
> The ABI Version being the issue.
>

This is due to switching default hash style from sysv to gnu starting
dunfell. You can switch back to sysv either via LDFLAGS
or explicitly define

LINKER_HASH_STYLE_mipsarch = "sysv"

in your distro.


Re: Additional log handler

Joshua Watt
 

On 8/24/20 8:26 AM, Richard Purdie wrote:
On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote:
The newer log handling uses Python's structure logging configuration
[1], so you should be able to use whatever capabilities it has
(including logging different domains/levels to a separate file). In
fact, this is the only way logging is handled by core bitbake now;
all of the other logging mechanisms used by the UI are additional
configuration specified on top of the user's BB_LOGCONFIG file. If
you are interested, you can see this in bitbake/lib/bb/ui/knotty.py.
In that file is an additional tool that might be helpful. Around line
553, there are two commented lines of code:

#import logging_tree
#logging_tree.printout()

uncommenting them and installing the logging_tree python package will
make bitbake dump the entire structured logging configuration to
stdout on startup so you can look at it.
On a slightly different but related note, could we remove the
debug_domains code now? I assume that can all be handled by
BB_LOGCONFIG?
Ah, right; you jogged my memory :) Structured logging still co-exists with the debug_domains, so it's not the *only* way the core speicfies logging messages. The main reason for this is that we still need to pass the set of active logging domains to the bitbake workers that they only send back requested logging levels over IPC instead of all log levels (per some code I believe you wrote Richard). It should the theoretically possible to send over the entire structured log config (which isn't very large) to the worker and add in worker side handlers to send back logs over IPC instead of the simplified list of logging domains (as a bonus, this should allow you to log anything on the worker, not just things in the "BitBake" domain). IIRC I tried to get this working in the original change, but it ended up being more complicated and not strictly necessary for the feature at hand (extra logging hashequiv on the AB) so I left in the debug_domain method of filtering in the workers. Since I had to leave that in, I also left in the UI code to directly deal with the debug domains. The log handling itself still all goes through Python logging, and it correctly merges the structured logging and user domains so that the actual logging domain level filter level passed to the workers is the lower of the user specified logging domain and whatever is specified for that domain in the structured config. The UI code could fairly easily be converted to instead map the command line arguments to structured logging configuration, which would remove any knowledge of them on the UI side.


TL;DR No, we can't remove it yet, but we could with some work.



Cheers,

Richard


meta-security

Massimo Anghilieri
 

Hello, I'm working with Yocto Sumo, I've successfully built and included in my image the sssd from meta-secutrity layer.

Now I need also SELimux in my image, but when including SELIinux I get the a do_configure failure  for the SSSD package. I've atttached the log file form bitbake. Can you pleass help me solving the problem?

Thank you very much

Massimo


Re: Additional log handler

Richard Purdie
 

On Mon, 2020-08-24 at 08:10 -0500, Joshua Watt wrote:
The newer log handling uses Python's structure logging configuration
[1], so you should be able to use whatever capabilities it has
(including logging different domains/levels to a separate file). In
fact, this is the only way logging is handled by core bitbake now;
all of the other logging mechanisms used by the UI are additional
configuration specified on top of the user's BB_LOGCONFIG file. If
you are interested, you can see this in bitbake/lib/bb/ui/knotty.py.
In that file is an additional tool that might be helpful. Around line
553, there are two commented lines of code:

#import logging_tree
#logging_tree.printout()

uncommenting them and installing the logging_tree python package will
make bitbake dump the entire structured logging configuration to
stdout on startup so you can look at it.
On a slightly different but related note, could we remove the
debug_domains code now? I assume that can all be handled by
BB_LOGCONFIG?

Cheers,

Richard


Re: Additional log handler

Joshua Watt
 


On 8/24/20 3:53 AM, Richard Purdie wrote:
On Sun, 2020-08-23 at 17:01 +0200, Konrad Weihmann wrote:
Hi all,

when running bitbake in CI I would like to add an additional log
handler to used python logging to catch *ALL* (task warnings,
dangling append, qa issues, a.s.o.), instead of manually grepping
through the console  log.
The information coming from this should be ideally be written to a
file, file, which can then serve as some sort of report.

Is there a way to do that?

In theory it should be possible to hook to an (obviously non-
existing) 
event and handle it from there, right?

Or am I thinking in the wrong direction?

Any pointers are appreciated from my side...
On the autobuilder the code simple watches the console log, filtering
on WARNING: and produces a separate warning stream. A non empty file
triggers the build to show a having warnings.

At the bitbake level it would also definitely be possible, the log
messages are seen in the UI code as events and it can do whatever it
wants with them.

There was a also much more advanced log handling added recently through
the BB_LOGCONFIG variable. I'm not sure if that can define a completely
separate stream or not, I've not tried that.

The newer log handling uses Python's structure logging configuration [1], so you should be able to use whatever capabilities it has (including logging different domains/levels to a separate file). In fact, this is the only way logging is handled by core bitbake now; all of the other logging mechanisms used by the UI are additional configuration specified on top of the user's BB_LOGCONFIG file. If you are interested, you can see this in bitbake/lib/bb/ui/knotty.py. In that file is an additional tool that might be helpful. Around line 553, there are two commented lines of code:

    #import logging_tree
    #logging_tree.printout()

uncommenting them and installing the logging_tree python package will make bitbake dump the entire structured logging configuration to stdout on startup so you can look at it.


[1]: https://docs.python.org/3/library/logging.config.html


Cheers,

Richard



    


Re: [PATCH 0/3] yocto-bsp/poky: kernel updates and default

Bruce Ashfield
 



On Sun, Aug 23, 2020 at 11:23 PM Mittal, Anuj <anuj.mittal@...> wrote:
Hi Bruce,

On Fri, 2020-08-21 at 15:07 -0400, Bruce Ashfield wrote:
> From: Bruce Ashfield <bruce.ashfield@...>
>
> Richard,
>
> Similar to oe-core, these are the patches I'm carrying to update the
> reference BSPs to the latest 5.4 (we still need a 5.8 bbappend and
> confirmed booting), as well as a switch to 5.8 as the default.
>
> That being said, I'm not sure of the way you'd like the default
> kernel
> set to differentiate between the reference BSPs and qemu. So
> currently,
> I just have the single preferred version set.
>

Should we also update PREFERRED_VERSION for linux-yocto-tiny for poky-
tiny DISTRO? It is currently pointing to 5.0 ...


Yup.

I take it that no one has been building that lately, since 5.0 zero has been gone for a while.

I'll take the action to check that out and make the changes. I'll do it along with some -rt preferred versions.

Bruce

 
Thanks,

Anuj


> Cheers,
>
> Bruce
>
> The following changes since commit
> c9d0bb421a2f7c6783f2c2bbf47c95da5537985d:
>
>   linux-yocto/5.8: update to v5.8.2 (2020-08-21 14:55:05 -0400)
>
> are available in the Git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zedd/kernel-yocto
>   
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto
>
> Bruce Ashfield (3):
>   poky: set preferred version for linux-yocto to be v5.8
>   yocto-bsp: update to v5.4.56
>   yocto-bsp: update to v5.4.58
>
>  meta-poky/conf/distro/poky.conf                  |  2 +-
>  .../linux/linux-yocto_5.4.bbappend               | 16 ++++++++----
> ----
>  2 files changed, 9 insertions(+), 9 deletions(-)
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: Yocto uses older PV instead of newest - how to figure out why?

Quentin Schulz
 

Hi Oliver,

On August 24, 2020 2:02:26 PM GMT+02:00, Oliver Westermann <oliver.westermann@cognex.com> wrote:
Hey,

we're porting our yocto from an older NXP iMX release to their newest
BSP, upgrading yocto in the process from sumo to zeus.
Using their current setup, the layers provide one recipe in two
versions - 0.2 and 1.0. imx-boot to be precise.

I assumed yocto would use the newer version, but it uses 0.2 for some
reason and I can't figure out why: I 'grep'ed' everything and could not
find any reference to this package which has some version requirements.
Are there any tips to figure out why yocto is not using the 1.0 recipe?
Everything I wanted to say is in this stack overflow answer: https://stackoverflow.com/a/37180291

If what Robert just answered isn't helping, this will (worth a read at least 😉). If all have been checked but you still couldn't figure it out, at least we got the obvious out of the way 🙂

BR,
Quentin
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: Yocto uses older PV instead of newest - how to figure out why?

Robert P. J. Day
 

Quoting Oliver Westermann <oliver.westermann@cognex.com>:

Hey,

we're porting our yocto from an older NXP iMX release to their newest BSP, upgrading yocto in the process from sumo to zeus.
Using their current setup, the layers provide one recipe in two versions - 0.2 and 1.0. imx-boot to be precise.

I assumed yocto would use the newer version, but it uses 0.2 for some reason and I can't figure out why: I 'grep'ed' everything and could not find any reference to this package which has some version requirements.
Are there any tips to figure out why yocto is not using the 1.0 recipe?
Could it have something to do with layer priorities? Use the
"bitbake-layers" utility to display where recipes are being
pulled from.

rday

3121 - 3140 of 53454