[yocto] SRTool usage for CVE management at YP

[Marta Rybczynska]

Hello all,
There' a discussion pending on the usage of SRTool and CVE management
for the Yocto project in general. It is related to the need of having
a list of CVEs the project is affected by, those fixed and those that
we know we are not affected.

In the previous episode, we have had a demo of SRTool by David Reyna.
This weekend he has updated the code base. The next call is tomorrow
(Thursday, 19th October, half an hour after the end of the Bug Triage
meeting) to discuss conclusions of first tests and the next steps. If
you are interested to join, let us know!

Kind regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61384): https://lists.yoctoproject.org/g/yocto/message/61384
Mute This Topic: https://lists.yoctoproject.org/mt/102034248/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-anaconda][PATCH] anaconda_oe.py: correct image name

[Changqing Li]

From: Changqing Li 

Since oe-core commit 26d97acc713 [image-artifact-names: include
${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and
${IMAGE_LINK_NAME}], image name has changed to
core-image-minimal-qemux86.rootfs.ext4, change accordingly to fix error:
INSTALLER_TARGET_BUILD does not exist

Signed-off-by: Changqing Li 
---
 README | 2 +-
 lib/oeqa/selftest/cases/anaconda_oe.py | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/README b/README
index 07b63fe..76e9665 100644
--- a/README
+++ b/README
@@ -162,7 +162,7 @@ Building the target installer
Edit conf/local.conf to use:
$ echo 'PACKAGE_CLASSES = "package_rpm"' >> conf/local.conf
$ echo 'DISTRO = "anaconda"' >> conf/local.conf
-   $ echo 'INSTALLER_TARGET_BUILD = 
"/tmp-glibc/deploy/images/qemux86/core-image-minimal-qemux86.ext4"'
 >> conf/local.conf
+   $ echo 'INSTALLER_TARGET_BUILD = 
"/tmp-glibc/deploy/images/qemux86/core-image-minimal-qemux86.rootfs.ext4"'
 >> conf/local.conf
 
Edit conf/bblayers.conf to include other layers
BBLAYERS ?= " \
diff --git a/lib/oeqa/selftest/cases/anaconda_oe.py 
b/lib/oeqa/selftest/cases/anaconda_oe.py
index bf55308..20b8d5b 100644
--- a/lib/oeqa/selftest/cases/anaconda_oe.py
+++ b/lib/oeqa/selftest/cases/anaconda_oe.py
@@ -146,7 +146,7 @@ class TestAnacondaOE(OESelftestTestCase):
 ks_file = os.path.join(self.layer_path, 'example/ks-imagecopy.cfg')
 features = 'TMPDIR .= "_host"\n'
 features += 'DISTRO = "%s"\n' % self.anaconda_distro
-features += 'INSTALLER_TARGET_BUILD = "%s/%s-%s.ext4"\n' % 
(self.target_deploy_dir_image, self.target_recipe, self.machine)
+features += 'INSTALLER_TARGET_BUILD = "%s/%s-%s.rootfs.ext4"\n' % 
(self.target_deploy_dir_image, self.target_recipe, self.machine)
 features += 'KICKSTART_FILE = "%s"\n' % ks_file
 features += 'SYSLINUX_TIMEOUT = "10"\n'
 features += 'APPEND:append = " textinst"\n'
@@ -164,7 +164,7 @@ class TestAnacondaOE(OESelftestTestCase):
 def test_testanaconda_imagecopy_install(self):
 features = 'TMPDIR .= "_host"\n'
 features += 'DISTRO = "%s"\n' % self.anaconda_distro
-features += 'INSTALLER_TARGET_BUILD = "%s/%s-%s.ext4"\n' % 
(self.target_deploy_dir_image, self.target_recipe, self.machine)
+features += 'INSTALLER_TARGET_BUILD = "%s/%s-%s.rootfs.ext4"\n' % 
(self.target_deploy_dir_image, self.target_recipe, self.machine)
 self.logger.info('extra local.conf:\n%s' % features)
 self.append_config(features)
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61383): https://lists.yoctoproject.org/g/yocto/message/61383
Mute This Topic: https://lists.yoctoproject.org/mt/102032096/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [yocto-autobuilder-helper][dunfell] config.json: update to latest buildtools tarball

[Steve Sakoman]

Signed-off-by: Steve Sakoman 
---
 config.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 03ea262..7ed8259 100644
--- a/config.json
+++ b/config.json
@@ -10,7 +10,7 @@
 
 "BUILDTOOLS_URL_TEMPLOCAL" : 
"/srv/autobuilder/autobuilder.yoctoproject.org/pub/non-release/20210214-8/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.2+snapshot-7d38cc8e749aedb8435ee71847e04b353cca541d.sh",
 "BUILDTOOLS_URL_TEMPLOCAL2" : 
"https://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M3/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.0+snapshot-20200315.sh;,
-"BUILDTOOLS_URL" : 
"https://downloads.yoctoproject.org/releases/yocto/yocto-3.4/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.4.sh;,
+"BUILDTOOLS_URL" : 
"/srv/autobuilder/autobuilder.yocto.io/pub/non-release/20230223-18/buildtools/x86_64-buildtools-extended-nativesdk-standalone-4.1+snapshot-9c07de0f20042c81496185293857284048d7912c.sh",
 
 "REPO_STASH_DIR" : "${BASE_HOMEDIR}/git/mirror",
 "TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61382): https://lists.yoctoproject.org/g/yocto/message/61382
Mute This Topic: https://lists.yoctoproject.org/mt/102028918/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] CDN for sstate.yoctoproject.org

[Alexander Kanavin]

Thanks for working on this! I finally got to playing with CDN mirror a
bit, and it seems to basically work ok, so next I'm going to write AB
tests that check that it remains useful. Specifically:

1. What should the test be?

I tried 'bitbake -S printdiff core-image-sato' on a blank build
directory, and the result against current master is:

===
Checking sstate mirror object availability: 100%
|##|
Time: 0:05:35
The differences between the current build and any cached tasks start
at the following tasks:
/srv/work/alex/poky/meta/recipes-sato/images/core-image-sato.bb:do_deploy_source_date_epoch
/srv/work/alex/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_install
===

I think this is pretty good! The two missing objects depend on the
current date, and so should go to the exception list in the test, and
otherwise there is a 100% match rate. The bitbake targets could be
'world core-image-sato-sdk', and target machines could be qemux86_64
and qemuarm64.

Just to be sure that mismatches elsewhere will be reported as CDN
misses, adding my shadow 4.14 update and re-running the command shows:

The differences between the current build and any cached tasks start
at the following tasks:
/srv/work/alex/poky/meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.17.bb:do_package
/srv/work/alex/poky/meta/recipes-sato/pulseaudio-sato/pulseaudio-client-conf-sato_1.bb:do_package
/srv/work/alex/poky/meta/recipes-core/initscripts/initscripts_1.0.bb:do_package
/srv/work/alex/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_package
/srv/work/alex/poky/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.10.bb:do_package
/srv/work/alex/poky/meta/recipes-kernel/wireless-regdb/wireless-regdb_2023.09.01.bb:do_package
/srv/work/alex/poky/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb:do_package
/srv/work/alex/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_6.5.bb:do_package
/srv/work/alex/poky/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb:do_package
/srv/work/alex/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11.bb:do_package
/srv/work/alex/poky/meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb:do_package
virtual:native:/srv/work/alex/poky/meta/recipes-support/libbsd/libbsd_0.11.7.bb:do_prepare_recipe_sysroot
/srv/work/alex/poky/meta/recipes-support/ca-certificates/ca-certificates_20211016.bb:do_package
/srv/work/alex/poky/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb:do_package
virtual:native:/srv/work/alex/poky/meta/recipes-extended/shadow/shadow_4.14.0.bb:do_recipe_qa
... (a few more missing do_package objects)
===

2. When to run the test, and against which commit in poky?

RP suggested that the test could run in an antiphase with the nightly
a-quick (i.e. 12 hours after). We can do that for a start, but I'm
(perhaps prematurely) worrying that this will be unstable: either
because the objects from the nightly haven't yet propagated to CDN, or
because master has meanwhile (e.g. in the 12 hours that have passed)
gained new commits without corresponding cache objects. Are those real
concerns?

Thoughts?

Alex


On Fri, 22 Sept 2023 at 19:32, Michael Halstead
 wrote:
>
> Right now we have https://cdn.jsdelivr.net/yocto/sstate set up as a CDN 
> mirroring proxy endpoint. It's fast and completely free to the project. 
> However, it will only work for files smaller than 64MB and will send a 
> redirect to the main server at sstate.yoctoproject.org for files larger than 
> 64MB.
>
> The good news is that we have a fast free CDN provided by 
> https://www.jsdelivr.com/ and their many sponsors for 99.4% of our files.
>
> Here is an estimated distribution of sstate files currently available:
> 1 KB-4 KB: 103168
> 4 KB-16 KB: 1218048
> 16 KB-64 KB: 1886976
> 64 KB-256 KB: 1225216
> 256 KB-1 MB: 170752
> 1 MB-4 MB: 92928
> 4 MB-16 MB: 83200
> 16 MB-64 MB: 40448
> 64 MB-256 MB: 17664
> 256 MB-1 GB: 7936
> 1 GB-4 GB: 2560
>
> I'm still working on a CDN solution for the larger files but we can begin 
> testing https://cdn.jsdelivr.net/yocto/sstate today.
>
> Here is an example link to a file that is currently popular from each 
> location:
>
> http://sstate.yoctoproject.org/all/universal/c6/81/sstate:re2c-native:x86_64-linux:3.1:r0:x86_64:11:c681f19e2786732c7920860d0b27cdcf3a79c9441d9bdaa82319a12e96e6246e_deploy_source_date_epoch.tar.zst
>
> https://cdn.jsdelivr.net/yocto/sstate/all/universal/c6/81/sstate:re2c-native:x86_64-linux:3.1:r0:x86_64:11:c681f19e2786732c7920860d0b27cdcf3a79c9441d9bdaa82319a12e96e6246e_deploy_source_date_epoch.tar.zst
>
> I'm also attaching a list of the largest files in sstate. Anything we can do 
> to reduce the size of these or to split them into smaller pieces will help 
> with hosting and with the user's download experience.
>
> --
> Michael 

Re: [yocto] Using cmake... how?

[Dave Hitchman]

Yeah, it is indeed, hence the changing the git address 

From: Ross Burton 
Sent: 17 October 2023 15:32
To: Dave Hitchman 
Cc: Mikko Rapeli ; yocto@lists.yoctoproject.org 

Subject: Re: [yocto] Using cmake... how?

On 17 Oct 2023, at 12:58, Dave Hitchman via lists.yoctoproject.org 
 wrote:
>
>
> I understand that, and the compiler the rest of the recipe uses does cope so 
> I am trying to understand why this bit of the whole thing is using a 
> different compiler. Maybe it is somewhere in the cmake of the library, but it 
> certainly isnt obvious. Thats where I am digging for the moment.

I presume this is a closed-source library so you can’t just share it?

The CMakeLists.txt are definitely doing The Wrong Thing by not respecting the 
environment the toolchain sets up.  Unfortunately this is now your problem to 
figure out exactly where and why it overrides the settings.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61380): https://lists.yoctoproject.org/g/yocto/message/61380
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Status 17 October 2023 (WW42)

[Neal Caidin]

Current Dev Position: YP 4.3 M4 (Feature Freeze)

Next Deadline: 2nd October 2023 YP 4.3 M4 build date

Next Team Meetings:

   -

   Bug Triage meeting Thursday October 19th 7:30 am PDT (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync Tuesday October 17th at 8 am PDT (
   https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
   
   -

   Twitch -  See https://www.twitch.tv/theyoctojester


Key Status/Updates:

   -

   The YP 4.3 (M4) rc1 build is still pending
   -

   For the 4.3 release, the 6.5 serial port issues are still presenting a
   challenge. We have merged a workaround which seems to fix things for the
   majority of cases. There is also a second proposed patch from upstream
   which may help. The dilemma is which option to go for in the release and
   the time implications of the choice as one is tested and one is not.
   -

   The only other potential issue for 4.3 is the strace ptest image space
   issues which is still being worked on.
   -

   Patchtest did merge to OE-Core and will be included in the release
   allowing users to locally test their patches before submission using the
   same code/tests we will ultimately run against mailing list submissions.
   This is late in the cycle but important to help users and standalone code
   so worthwhile adding since it was ready. Thanks Trevor!
   -

   There were multiple CVE fixes merged over the last week to ensure the
   release had recent widely publicized CVEs addressed.
   -

   Toaster has had upgrades to key components which help address security
   issues and patches are merging to enable testing to be resumed and
   ultimately, automated.
   -

   There was a big improvement in reproducibility for rust. Unfortunately
   this hasn’t addressed all the issues but is a big step forward and great to
   see progress on what was a really difficult to track down issue, thanks
   Sundeep.
   -

   The project is pleased to have a new content delivery network (CDN)
   available to share sstate from the autobuilder with. See the entry in
   local.conf.sample on how to use it.
   -

   After consultation and discussions the project is now about to document
   its security processes to complete the work in this area. Please watch the
   mailing lists such as the architecture list if you have an interest in this
   area.


Ways to contribute:

   -

   As people are likely aware, the project has a number of components which
   are either unmaintained, or have people with little to no time trying to
   keep them alive. These components include: patchtest, layerindex, devtool,
   toaster, wic, oeqa, autobuilder, CROPs containers, pseudo and more. Many
   have open bugs. Help is welcome in trying to better look after these
   components!
   -

   There are bugs identified as possible for newcomers to the project:
   https://wiki.yoctoproject.org/wiki/Newcomers
   -

   There are bugs that are currently unassigned for YP 4.3. See:
   
https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.3_Unassigned_Enhancements.2FBugs
   -

   We’d welcome new maintainers for recipes in OE-Core. Please see the list
   at:
   
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
   and discuss with the existing maintainer, or ask on the OE-Core mailing
   list. We will likely move a chunk of these to “Unassigned” soon to help
   facilitate this.
   -

   Help is very much welcome in trying to resolve our autobuilder
   intermittent issues. You can see the list of failures we’re continuing to
   see by searching for the “AB-INT” tag in bugzilla:
   https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
   -

   Help us resolve CVE issues: CVE metrics
   
   -

   We have a growing number of bugs in bugzilla, any help with them is
   appreciated.


YP 4.3 Milestone Dates:

   -

   YP 4.3 M3 was released.
   -

   YP 4.3 M4 build date  2023/10/02
   -

   YP 4.3 M4 Release date 2023/10/27


YP 5.0 Milestone Dates:

   -

   YP 5.0 M1 build date 2023/12/04
   -

   YP 5.0 M1 Release date 2023/12/15
   -

   YP 5.0 M2 build date  2024/01/15
   -

   YP 5.0 M2 Release date 2024/01/24
   -

   YP 5.0 M3 build date  2024/02/19
   -

   YP 5.0 M3 Release date 2024/03/01
   -

   YP 5.0 M4 build date  2024/04/01
   -

   YP 5.0 M4 Release date 2024/04/30


Upcoming dot releases:

   -

   YP 3.1.29 build date 2023/10/30
   -

   YP 3.1.29 Release date 2023/11/10
   -

   YP 4.0.14 build date 2023/11/06
   -

   YP 4.0.14 Release date 2023/11/17
   -

   YP 4.2.4 build date 2023/11/13
   -

   YP 4.2.4 Release date 2023/11/24
   -

   YP 4.3.1 build date 2023/11/27
   -

   YP 4.3.1 Release date 2023/12/08
   -

   YP 3.1.30 build date 2023/12/11
   -

   YP 3.1.30 Release date 2023/12/22
   -

   YP 4.0.15 build date 2023/12/18
   -

   YP 4.0.15 Release date 

Re: [yocto] example where "RDEPENDS" is including a "virtual/" run-time dependency

[Ross Burton]

On 17 Oct 2023, at 12:56, Robert P. J. Day via lists.yoctoproject.org 
 wrote:
> 
> 
>  while the dev manual insists that "virtual/" dependencies are only
> for build-time deps and not run-time deps, i ran across this example
> on the meta-intel master branch, under
> dynamic-layers/openembedded-layer/recipes-oneapi/ (blank lines added
> for clarity):
> 
> $ grep -r "RDEPENDS.*virtual/" *
> 
> compiler/intel-oneapi-compiler_2023.0.0-25370.bb:RDEPENDS:${PN} +=
> "perl elfutils virtual/opencl-icd level-zero-loader zlib tbb libelf
> setup-intel-oneapi-env"
> 
> dpcpp-compiler/intel-oneapi-dpcpp-cpp-runtime_2023.1.0-46305.bb:RDEPENDS:${PN}
> += "virtual/opencl-icd zlib tbb level-zero-loader bash tcsh"
> 
> mkl/intel-oneapi-mkl_2023.0.0-25398.bb:RDEPENDS:${PN} += "bash tbb
> intel-oneapi-compiler setup-intel-oneapi-env virtual/opencl-icd"
> 
>  i have no opinion on it, just observing that it seems to fly in the
> face of the rules laid down in the dev manual:

Correct, you’ve found a bug.

It’s unconventional to use virtual/ as runtime names. The root of the bug is 
here:

meta-oe/recipes-core/opencl/opencl-icd-loader_git.bb:RPROVIDES:${PN} = 
"virtual/opencl-icd”

That should be virtual-opencl-icd and the change pushed to all the dependent 
recipes.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61378): https://lists.yoctoproject.org/g/yocto/message/61378
Mute This Topic: https://lists.yoctoproject.org/mt/102015778/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Ross Burton]

On 17 Oct 2023, at 12:58, Dave Hitchman via lists.yoctoproject.org 
 wrote:
> 
> 
> I understand that, and the compiler the rest of the recipe uses does cope so 
> I am trying to understand why this bit of the whole thing is using a 
> different compiler. Maybe it is somewhere in the cmake of the library, but it 
> certainly isnt obvious. Thats where I am digging for the moment.

I presume this is a closed-source library so you can’t just share it?

The CMakeLists.txt are definitely doing The Wrong Thing by not respecting the 
environment the toolchain sets up.  Unfortunately this is now your problem to 
figure out exactly where and why it overrides the settings.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61377): https://lists.yoctoproject.org/g/yocto/message/61377
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Mikko Rapeli]

Hi,

On Tue, Oct 17, 2023 at 11:58:23AM +, Dave Hitchman wrote:
> I understand that, and the compiler the rest of the recipe uses does cope so 
> I am trying to understand why this bit of the whole thing is using a 
> different compiler. Maybe it is somewhere in the cmake of the library, but it 
> certainly isnt obvious. Thats where I am digging for the moment.

One thing could be CMake calls to sub projects/directories/modules where the
toolchain file is not propagated. So first level CMake gets correctly called 
with
cross compile toolchain file but second or third level ones not. These are
annoyingly tricky to spot. It makes sense to change the do_configure
task calls to cmake be as verbose as possible. CMake doesn't make these easy.

Hope this helps,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61376): https://lists.yoctoproject.org/g/yocto/message/61376
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Dave Hitchman]

I understand that, and the compiler the rest of the recipe uses does cope so I 
am trying to understand why this bit of the whole thing is using a different 
compiler. Maybe it is somewhere in the cmake of the library, but it certainly 
isnt obvious. Thats where I am digging for the moment.

From: Mikko Rapeli 
Sent: 17 October 2023 13:53
To: Dave Hitchman 
Cc: yocto@lists.yoctoproject.org 
Subject: Re: [yocto] Using cmake... how?

Hi,

On Tue, Oct 17, 2023 at 11:35:13AM +, Dave Hitchman wrote:

> | /usr/bin/g++   -O2 -pipe -g -feliminate-unused-debug-types 
> -fmacro-prefix-map=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0=/usr/src/debug/libkymati/1.0-r0
>   
> -fdebug-prefix-map=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0=/usr/src/debug/libkymati/1.0-r0
>   
> -fdebug-prefix-map=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/recipe-sysroot=
>   
> -fdebug-prefix-map=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/recipe-sysroot-native=
>   -fvisibility-inlines-hidden  -mcpu=cortex-a53 -march=armv8-a+crc+crypto 
> -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
> -Werror=format-security  
> --sysroot=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/recipe-sysroot
>  -o CMakeFiles/cmTC_e06e9.dir/testCXXCompiler.cxx.o -c testCXXCompiler.cxx
> | g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
> | cc1plus: error: bad value (‘armv8-a+crc+crypto’) for ‘-march=’ switch
> | cc1plus: note: valid arguments to ‘-march=’ switch are: nocona core2 
> nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell 
> core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client 
> icelake-server cascadelake tigerlake bonnell atom silvermont slm goldmont 
> goldmont-plus tremont knl knm x86-64 eden-x2 nano nano-1000 nano-2000 
> nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 
> athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 
> znver2 btver1 btver2 native

For example here the "/usr/bin/g++" compiler will not understand 
-mcpu=cortex-a53 flags
since the compiler is on the Linux build machine and compiling natively for 
x86_64 target
architecture, this is not the yocto/bitbake cross compiler. The correct 
compiler binary
is set via CMAKE_CXX_COMPILER variable in the toolchain file and path to it is 
somewhere
in the recipe specific native sysroot path. CMake build scripts of libkymati 
must use those
variables from the toolchain file. They must not overwrite them with their own 
guesses
like /usr/bin/g++.

Further details depends on what kind of CMake build scripts libkymati has.

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61375): https://lists.yoctoproject.org/g/yocto/message/61375
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] example where "RDEPENDS" is including a "virtual/" run-time dependency

[Robert P. J. Day]

  while the dev manual insists that "virtual/" dependencies are only
for build-time deps and not run-time deps, i ran across this example
on the meta-intel master branch, under
dynamic-layers/openembedded-layer/recipes-oneapi/ (blank lines added
for clarity):

$ grep -r "RDEPENDS.*virtual/" *

compiler/intel-oneapi-compiler_2023.0.0-25370.bb:RDEPENDS:${PN} +=
"perl elfutils virtual/opencl-icd level-zero-loader zlib tbb libelf
setup-intel-oneapi-env"

dpcpp-compiler/intel-oneapi-dpcpp-cpp-runtime_2023.1.0-46305.bb:RDEPENDS:${PN}
+= "virtual/opencl-icd zlib tbb level-zero-loader bash tcsh"

mkl/intel-oneapi-mkl_2023.0.0-25398.bb:RDEPENDS:${PN} += "bash tbb
intel-oneapi-compiler setup-intel-oneapi-env virtual/opencl-icd"

  i have no opinion on it, just observing that it seems to fly in the
face of the rules laid down in the dev manual:

https://docs.yoctoproject.org/dev-manual/new-recipe.html#using-virtual-providers

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61374): https://lists.yoctoproject.org/g/yocto/message/61374
Mute This Topic: https://lists.yoctoproject.org/mt/102015778/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Mikko Rapeli]

Hi,

On Tue, Oct 17, 2023 at 11:35:13AM +, Dave Hitchman wrote:

> | /usr/bin/g++   -O2 -pipe -g -feliminate-unused-debug-types 
> -fmacro-prefix-map=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0=/usr/src/debug/libkymati/1.0-r0
>   
> -fdebug-prefix-map=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0=/usr/src/debug/libkymati/1.0-r0
>   
> -fdebug-prefix-map=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/recipe-sysroot=
>   
> -fdebug-prefix-map=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/recipe-sysroot-native=
>   -fvisibility-inlines-hidden  -mcpu=cortex-a53 -march=armv8-a+crc+crypto 
> -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
> -Werror=format-security  
> --sysroot=/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/recipe-sysroot
>  -o CMakeFiles/cmTC_e06e9.dir/testCXXCompiler.cxx.o -c testCXXCompiler.cxx
> | g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
> | cc1plus: error: bad value (‘armv8-a+crc+crypto’) for ‘-march=’ switch
> | cc1plus: note: valid arguments to ‘-march=’ switch are: nocona core2 
> nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell 
> core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client 
> icelake-server cascadelake tigerlake bonnell atom silvermont slm goldmont 
> goldmont-plus tremont knl knm x86-64 eden-x2 nano nano-1000 nano-2000 
> nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 
> athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 
> znver2 btver1 btver2 native

For example here the "/usr/bin/g++" compiler will not understand 
-mcpu=cortex-a53 flags
since the compiler is on the Linux build machine and compiling natively for 
x86_64 target
architecture, this is not the yocto/bitbake cross compiler. The correct 
compiler binary
is set via CMAKE_CXX_COMPILER variable in the toolchain file and path to it is 
somewhere
in the recipe specific native sysroot path. CMake build scripts of libkymati 
must use those
variables from the toolchain file. They must not overwrite them with their own 
guesses
like /usr/bin/g++.

Further details depends on what kind of CMake build scripts libkymati has.

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61373): https://lists.yoctoproject.org/g/yocto/message/61373
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Mikko Rapeli]

Hi,

On Tue, Oct 17, 2023 at 11:35:13AM +, Dave Hitchman wrote:
> Thanks, but without the CXX settings there is no difference either, it still 
> uses the wrong toolchain (or rather tries to and fails in the same way) . I 
> have now removed the two export CXX type lines...

Check the CMakeFile.txt etc scripts in the SW component. They are likely 
overwriting
variables like CXX. Alternatively, they are trying to mix host (-native) and 
target
compilation in one step by compiling code generators etc tools.

If something on bitbake side is setting CXX etc variables, those can be seen
with "bitbake -e recipe".

Sadly these issues are quite common for SW which has not been cross compiled 
before..

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61372): https://lists.yoctoproject.org/g/yocto/message/61372
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Dave Hitchman]

Thanks, but without the CXX settings there is no difference either, it still 
uses the wrong toolchain (or rather tries to and fails in the same way) . I 
have now removed the two export CXX type lines...


bitbake -c configure custom-image-mpet
Loading cache: 100% 
|###|
 Time: 0:00:00
Loaded 5337 entries from dependency cache.
Parsing recipes: 100% 
|#|
 Time: 0:00:00
Parsing of 3640 .bb files complete (3639 cached, 1 parsed). 5336 targets, 576 
skipped, 1 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.50.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-phytec-linux"
MACHINE  = "phyboard-pollux-imx8mp-2"
DISTRO   = "ampliphy-vendor"
DISTRO_VERSION   = "BSP-Yocto-NXP-i.MX8MP-PD22.1.1"
TUNE_FEATURES= "aarch64 armv8a crc cortexa53 crypto"
TARGET_FPU   = ""
meta
meta-poky= "HEAD:269265c00091fa65f93de6cad32bf24f1e7f72a3"
meta-oe
meta-networking
meta-python
meta-multimedia
meta-filesystems
meta-perl
meta-gnome   = "HEAD:f44e1a2b575826e88b8cb2725e54a7c5d29cf94a"
meta-bsp
meta-sdk
meta-ml  = "HEAD:cc4c2d1c845b48fdec989f089aee3c13d2b1e15b"
meta-chromium= "HEAD:8be1d3a0ba0cf32e61144900597207af5698c10d"
meta-clang   = "HEAD:b0d805060791006d651efd3d7ae3dd5add8f70fe"
meta-freescale   = "HEAD:f0be684f01b53482cb43e016a5c5c1faf3ae448e"
meta-freescale-3rdparty = "HEAD:f8150f3b37cb83cba1f9e2378e57bb63e02d4610"
meta-freescale-distro = "HEAD:e6daa26ba1f748326546063d63a085ae671827d9"
meta-nxp-demo-experience = "HEAD:9dcc11ea9f525cffedbb28895e0abb443e56c3e0"
meta-python2 = "HEAD:8db9e4f6ceae33d7a4f55453d31e69f9858af4eb"
meta-qt5 = "HEAD:43f8f539d40070a70fe89136db89bf5bb1dfe7ed"
meta-virtualization  = "HEAD:7f719ef40896b6c78893add8485fda995b00d51d"
meta-rauc= "HEAD:b344adecae6cef9a26b3c5b6a7bb344d18c074a6"
meta-phytec  = "HEAD:f023740382f01e85151a67843a08d9d965503961"
meta-ampliphy= "HEAD:d761395629c0f8f0d06f9fd6fe128fdb001fdfec"
meta-security
meta-tpm = "HEAD:c40e1e84da9624b9096a463dbed3b301c01c268e"
meta-custom-mpet = "master:19ff82126c1239c9fe258555b10ee2e44d7f651a"

Initialising tasks: 100% 
|##|
 Time: 0:00:03
Sstate summary: Wanted 8 Local 4 Network 0 Missed 4 Current 193 (50% match, 98% 
complete)
Removing 1 stale sstate objects for arch phyboard_pollux_imx8mp_2: 100% 
|###|
 Time: 0:00:00
NOTE: Executing Tasks
WARNING: optee-os-3.15.0.imx-r0 do_optee_warning: OP-TEE support is 
experimental and not ready for production use
NOTE: Tasks Summary: Attempted 891 tasks of which 885 didn't need to be rerun 
and all succeeded.
NOTE: Writing buildhistory
NOTE: Writing buildhistory took: 3 seconds

Summary: There was 1 WARNING message shown.
dave@dave-TUXEDO-Aura-15-Gen1:~/Documents/Kymati/yocto/build$




bitbake -c compile custom-image-mpet
Loading cache: 100% 
|###|
 Time: 0:00:00
Loaded 5337 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.50.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-phytec-linux"
MACHINE  = "phyboard-pollux-imx8mp-2"
DISTRO   = "ampliphy-vendor"
DISTRO_VERSION   = "BSP-Yocto-NXP-i.MX8MP-PD22.1.1"
TUNE_FEATURES= "aarch64 armv8a crc cortexa53 crypto"
TARGET_FPU   = ""
meta
meta-poky= "HEAD:269265c00091fa65f93de6cad32bf24f1e7f72a3"
meta-oe
meta-networking
meta-python
meta-multimedia
meta-filesystems
meta-perl
meta-gnome   = "HEAD:f44e1a2b575826e88b8cb2725e54a7c5d29cf94a"
meta-bsp
meta-sdk
meta-ml  = "HEAD:cc4c2d1c845b48fdec989f089aee3c13d2b1e15b"
meta-chromium= "HEAD:8be1d3a0ba0cf32e61144900597207af5698c10d"
meta-clang   = "HEAD:b0d805060791006d651efd3d7ae3dd5add8f70fe"
meta-freescale   = "HEAD:f0be684f01b53482cb43e016a5c5c1faf3ae448e"
meta-freescale-3rdparty = "HEAD:f8150f3b37cb83cba1f9e2378e57bb63e02d4610"
meta-freescale-distro = "HEAD:e6daa26ba1f748326546063d63a085ae671827d9"
meta-nxp-demo-experience = "HEAD:9dcc11ea9f525cffedbb28895e0abb443e56c3e0"
meta-python2 = "HEAD:8db9e4f6ceae33d7a4f55453d31e69f9858af4eb"
meta-qt5 = "HEAD:43f8f539d40070a70fe89136db89bf5bb1dfe7ed"

Re: [yocto] Using cmake... how?

[Mikko Rapeli]

Hi,

On Tue, Oct 17, 2023 at 10:09:42AM +, Dave Hitchman wrote:
> Thanks
> 
> So, first, I thought - as I had seen examples that I had to put these flags 
> etc. in the configuration function but it appears that was a wrong thing.
> Now my recipe looks like:
> SUMMARY = "mylib"
> DESCRIPTION = "Fetch and build mylibi"
> LICENSE = "CLOSED"
> LIC_FILES_CHKSUM = ""
> 
> ##EXTRA_OECMAKE = "all"
> inherit cmake
> 
> python do_display_banner() {
> bb.plain("***");
> bb.plain("* *");
> bb.plain("*  mylibrecipe created by mei *");
> bb.plain("* *");
> bb.plain("***");
> }
> 
> addtask display_banner before do_build
> 
> # where and how to get source
> ## this is via git
> SRC_URI = "git://git@correct git - this works;"
> 
> # where to source is stored
> S = "${WORKDIR}/git"
> 
> ## was using target flags but Mikko suggested EXTRA_OECMAKE which at least 
> doesnt complain
> ##TARGET_CFLAGS += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
> -DBUILD_TOOLS=ON"
> ##TARGET_CXXFLAGS += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
> -DBUILD_TOOLS=ON"
> EXTRA_OECMAKE += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
> -DBUILD_TOOLS=ON"
> 
> ## this I think is needed to ensure the correct compilers are used... I think 
> anyway.
> export CXX="/usr/bin/arm-none-gnueabi-g++"
> export CMAKE_CXX_COMPILER="/usr/bin/arm-none-gnueabi-g++"

This is wrong. cmake.bbclass generates a toolchain file which is given
to cmake binary and this has all the compiler, binary, module, header file etc
search paths set correctly. It's up to the CMake scripts of the SW component to 
obey
these settings and not overwrite them. The SW component can amend them by 
appending
to them but not overwriting. An overwrite of any variable from toolchain.cmake
will break things in various ways. Run the "bitbake -c configure && bitbake -c 
compile" steps
manually and check the environment in a "bitbake -c devshell", for example.

> However:
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing shell function do_configure
> | -- The CXX compiler identification is GNU 9.4.0
> | -- The C compiler identification is GNU 9.4.0
> | -- Detecting CXX compiler ABI info
> | -- Detecting CXX compiler ABI info - failed
> | -- Check for working CXX compiler: /usr/bin/g++
> | -- Check for working CXX compiler: /usr/bin/g++ - broken
> | CMake Error at 
> /home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/recipe-sysroot-native/usr/share/cmake-3.19/Modules/CMakeTestCXXCompiler.cmake:59
>  (message):
> |   The C++ compiler
> |
> | "/usr/bin/g++"
> |
> |   is not able to compile a simple test program.
> |
> 
> suggesting it is not using the c++ I thought it should be.

Yes, as said before, using the host compiled from the Linux machine instead of
yocto cross compiler for real target.

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61370): https://lists.yoctoproject.org/g/yocto/message/61370
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Dave Hitchman]

Thanks

So, first, I thought - as I had seen examples that I had to put these flags 
etc. in the configuration function but it appears that was a wrong thing.
Now my recipe looks like:
SUMMARY = "mylib"
DESCRIPTION = "Fetch and build mylibi"
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

##EXTRA_OECMAKE = "all"
inherit cmake

python do_display_banner() {
bb.plain("***");
bb.plain("* *");
bb.plain("*  mylibrecipe created by mei *");
bb.plain("* *");
bb.plain("***");
}

addtask display_banner before do_build

# where and how to get source
## this is via git
SRC_URI = "git://git@correct git - this works;"

# where to source is stored
S = "${WORKDIR}/git"

## was using target flags but Mikko suggested EXTRA_OECMAKE which at least 
doesnt complain
##TARGET_CFLAGS += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
-DBUILD_TOOLS=ON"
##TARGET_CXXFLAGS += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
-DBUILD_TOOLS=ON"
EXTRA_OECMAKE += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON -DBUILD_TOOLS=ON"

## this I think is needed to ensure the correct compilers are used... I think 
anyway.
export CXX="/usr/bin/arm-none-gnueabi-g++"
export CMAKE_CXX_COMPILER="/usr/bin/arm-none-gnueabi-g++"




However:
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_configure
| -- The CXX compiler identification is GNU 9.4.0
| -- The C compiler identification is GNU 9.4.0
| -- Detecting CXX compiler ABI info
| -- Detecting CXX compiler ABI info - failed
| -- Check for working CXX compiler: /usr/bin/g++
| -- Check for working CXX compiler: /usr/bin/g++ - broken
| CMake Error at 
/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/recipe-sysroot-native/usr/share/cmake-3.19/Modules/CMakeTestCXXCompiler.cmake:59
 (message):
|   The C++ compiler
|
| "/usr/bin/g++"
|
|   is not able to compile a simple test program.
|





suggesting it is not using the c++ I thought it should be.

From: Mikko Rapeli 
Sent: 17 October 2023 11:52
To: Dave Hitchman 
Cc: yocto@lists.yoctoproject.org 
Subject: Re: [yocto] Using cmake... how?

Hi,

On Tue, Oct 17, 2023 at 09:21:27AM +, Dave Hitchman wrote:
> Oh I dont know. This is getting to be a bit annoying.
> I had already included the inherit cmake line but now it seems maybe that you 
> dont need to put any cmake commands in... not 100% sure, no one seems to 
> explain this, I am not convinced.
> However I want some extra flags and I have read that you should be able to:
> TARGET_CFLAGS += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
> -DBUILD_TOOLS=ON"

Don't put these into CFLAGS. I presume you want to give these to CMake via 
EXTRA_OECMAKE
variable to be used at do_configure time. Check poky tree for documentation and 
examples,
docs are also here:

https://docs.yoctoproject.org/dev/singleindex.html#cmake

> but building that gives me
> + cd 
> /home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/build
> + do_configure
> + cd 
> /home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/git
> + TARGET_CFLAGS:=-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON -DBUILD_TOOLS=ON
>
> /home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/temp/run.do_configure.991537:
>  159: TARGET_CFLAGS:=-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
> -DBUILD_TOOLS=ON: not found
>
> Is there a good, really works, actually sets extra flags, really shows and 
> explains with comments and everything example I can look at?  This bitbake is 
> clearly clever, so is cmake, but in honesty I really gave up trying to 
> understand any of it and just want it to work, writing the code is one thing 
> but these build systems are a fight all of their own that takes longer than 
> the code to solve the universe

Build systems are hard. I'm sure someone will invent another one to solve all 
issues
and resurrect all old ones. :)

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61369): https://lists.yoctoproject.org/g/yocto/message/61369
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Mikko Rapeli]

Hi,

On Tue, Oct 17, 2023 at 09:21:27AM +, Dave Hitchman wrote:
> Oh I dont know. This is getting to be a bit annoying.
> I had already included the inherit cmake line but now it seems maybe that you 
> dont need to put any cmake commands in... not 100% sure, no one seems to 
> explain this, I am not convinced.
> However I want some extra flags and I have read that you should be able to:
> TARGET_CFLAGS += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
> -DBUILD_TOOLS=ON"

Don't put these into CFLAGS. I presume you want to give these to CMake via 
EXTRA_OECMAKE
variable to be used at do_configure time. Check poky tree for documentation and 
examples,
docs are also here:

https://docs.yoctoproject.org/dev/singleindex.html#cmake

> but building that gives me
> + cd 
> /home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/build
> + do_configure
> + cd 
> /home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/git
> + TARGET_CFLAGS:=-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON -DBUILD_TOOLS=ON
> 
> /home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/temp/run.do_configure.991537:
>  159: TARGET_CFLAGS:=-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
> -DBUILD_TOOLS=ON: not found
> 
> Is there a good, really works, actually sets extra flags, really shows and 
> explains with comments and everything example I can look at?  This bitbake is 
> clearly clever, so is cmake, but in honesty I really gave up trying to 
> understand any of it and just want it to work, writing the code is one thing 
> but these build systems are a fight all of their own that takes longer than 
> the code to solve the universe

Build systems are hard. I'm sure someone will invent another one to solve all 
issues
and resurrect all old ones. :)

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61368): https://lists.yoctoproject.org/g/yocto/message/61368
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using cmake... how?

[Dave Hitchman]

Oh I dont know. This is getting to be a bit annoying.
I had already included the inherit cmake line but now it seems maybe that you 
dont need to put any cmake commands in... not 100% sure, no one seems to 
explain this, I am not convinced.
However I want some extra flags and I have read that you should be able to:
TARGET_CFLAGS += "-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON -DBUILD_TOOLS=ON"

but building that gives me
+ cd 
/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/build
+ do_configure
+ cd 
/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/git
+ TARGET_CFLAGS:=-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON -DBUILD_TOOLS=ON

/home/dave/Documents/Kymati/yocto/build/tmp/work/cortexa53-crypto-phytec-linux/libkymati/1.0-r0/temp/run.do_configure.991537:
 159: TARGET_CFLAGS:=-DBUILD_PYTHON_BINDINGS=ON -DBUILD_SHARED=ON 
-DBUILD_TOOLS=ON: not found


Is there a good, really works, actually sets extra flags, really shows and 
explains with comments and everything example I can look at?  This bitbake is 
clearly clever, so is cmake, but in honesty I really gave up trying to 
understand any of it and just want it to work, writing the code is one thing 
but these build systems are a fight all of their own that takes longer than the 
code to solve the universe

From: Mikko Rapeli 
Sent: 17 October 2023 07:49
To: Dave Hitchman 
Cc: yocto@lists.yoctoproject.org 
Subject: Re: [yocto] Using cmake... how?

Hi,

On Mon, Oct 16, 2023 at 03:27:01PM +, Dave Hitchman wrote:
> So my current recipe for the project works, including building various C, C++ 
> files
> I wanted to now add a library of someone elses creation.
> On my machine this library builds using the tools installed so the code is ok
>
> I added a recipe to my yocto build and it attempts to do the cmake.
>
> Unfortunately whatever I have tried over 2 days cmake insists:
>
>   1.  On using the from my machine NOT the cross compiling tool set the rest 
> of the yocto build uses.
> | -- The CXX compiler identification is GNU 9.4.0
> | -- The C compiler identification is GNU 9.4.0
>   2.
> Getting upset about the flags passed in:
> | g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
> | cc1plus: error: bad value (‘armv8-a+crc+crypto’) for ‘-march=’ switch
> I cant even find where these flags are actually set, where I found them and 
> thought they were set I altered them to be FRED and nothing changed in the 
> errors at all.
>
> Any idea? Surely it should be pretty easy?

"inherit cmake" in the recipe and then fix the CMake scripts to use variables 
from
the toolchain file and only append to them. Same problems in all build tools. 
CMake
adds several abstractions on top though so finding out the details may be 
tricky.
See the toolchain.cmake file in recipe build directory. If this is not followed
wrong compiler can be used, with wrong flags, using wrong binary, module and 
header file
search paths...

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61367): https://lists.yoctoproject.org/g/yocto/message/61367
Mute This Topic: https://lists.yoctoproject.org/mt/101998042/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-