[yocto] RHEL 8 support under Yocto

[Monsees, Steven C (US) via lists.yoctoproject.org]

Hello:

With RHEL 7 (Linux) reaching End of Life (EOL) and no longer be mainstream 
supported, We will be updating systems to RHEL 8.

Which versions of Yocto currently support RHEL 8 ?

We are currently using the Yocto Zeus release, and will most likely need to 
port forward.

Thank you,
Steve














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

[yocto] linux script command

[Monsees, Steven C (US) via lists.yoctoproject.org]

Does Yocto support the Linux script command, and how would I enable it for 
kernel use ?

I am currently using Zeus release...

Thanks,
Steve

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

[yocto] Does yocto to support a package for bitwise functionality ?

[Monsees, Steven C (US) via lists.yoctoproject.org]

Hello:

Is there a package I can install under Yocto so that scripts can perform 
bitwise functions, to help with converting the read hex data into the correct 
unit of measurement, i.e. mV, watts, etc. ?

Thanks,
Steve

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

[yocto] Thud/Zeus support of Linux "memtester"

[Monsees, Steven C (US) via lists.yoctoproject.org]

Does Yocto thud/zeus support the linux "memtester", to find memory subsystem  
faults ?

Whay packages would need to be included to support this utility ?

Thanks,
Steve

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

Re: [yocto] devtool upgrade for go recipes with git "broken"

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks...

-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Alexander Kanavin
Sent: Thursday, October 20, 2022 6:40 AM
To: Roos, Thomas 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] devtool upgrade for go recipes with git "broken"

External Email Alert

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

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


It may well be that no one remembers anymore why it's there, and in this case 
you can just drop it. Or you can dig into git history with 'git blame' and 
similar techniques.

Alex

On Thu, 20 Oct 2022 at 12:23, Roos, Thomas  wrote:
>
> sure, but may this src folder is necessary for something? Some go convention 
> I don't know about...
>
> 
> Von: Alexander Kanavin 
> Gesendet: Donnerstag, 20. Oktober 2022 12:09:47
> An: Roos, Thomas
> Cc: yocto@lists.yoctoproject.org
> Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git 
> "broken"
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
>
>
>
> Can you propose a patch to core?
>
> Alex
>
> On Thu, 20 Oct 2022 at 12:05, Roos, Thomas  wrote:
> >
> > yes, I already did this - it's because that go.bbclass is spangly using a 
> > subdir called "src" and that will break the devtool check for upgrades 
> > mechanism because it's not looking into a src subdir. So git will fail 
> > checkout anything in the parent dir "reference is not a tree"
> >
> > This simple change in the go.bbclass fix it - but I don't know if that 
> > additional src dir is somehow necessary:
> >
> >
> > # src folder will break devtool upgrade python go_do_unpack() {
> > src_uri = (d.getVar('SRC_URI') or "").split()
> > if len(src_uri) == 0:
> > return
> >
> > fetcher = bb.fetch2.Fetch(src_uri, d)
> > for url in fetcher.urls:
> > if fetcher.ud[url].type == 'git':
> > if fetcher.ud[url].parm.get('destsuffix') is None:
> > s_dirname = os.path.basename(d.getVar('S'))
> > #cause problemsfetcher.ud[url].parm['destsuffix'] = 
> > os.path.join(s_dirname, 'src', d.getVar('GO_IMPORT')) + '/'
> > #FIX
> > fetcher.ud[url].parm['destsuffix'] = 
> > os.path.join(s_dirname, '', d.getVar('GO_IMPORT')) + '/'
> > #FIX
> > fetcher.unpack(d.getVar('WORKDIR'))
> > }
> >
> > # src folder will break devtool upgrade
> > go_do_configure() {
> > #cause problems  ln -snf ${S}/src ${B}/
> > #FIX
> > ln -snf ${S} ${B}/
> > #FIX
> > }
> >
> >
> > 
> > Von: Alexander Kanavin 
> > Gesendet: Donnerstag, 20. Oktober 2022 11:56:48
> > An: Roos, Thomas
> > Cc: yocto@lists.yoctoproject.org
> > Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git 
> > "broken"
> >
> > CAUTION: This email originated from outside of the organization. Do not 
> > click links or open attachments unless you can confirm the sender and know 
> > the content is safe.
> >
> >
> >
> > Thanks, I do not have a quick answer to this, but would appreciate 
> > if you can dig deeper into the issue.
> >
> > Alex
> >
> > On Thu, 20 Oct 2022 at 11:50, Roos, Thomas  wrote:
> > >
> > > yes, easy
> > > - set the go-helloworld bb srcrev to an older rev - e.g:
> > > SRCREV = "ad95e7f791d8e1e7e7ec7f7cedfc2f6b29f6c9e2"
> > >
> > > "devtool upgrade go-helloworld"
> > >
> > > INFO: Extracting upgraded version source...
> > > Traceback (most recent call last):
> > >   File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 
> > > 567, in upgrade
> > > rev2, md5, sha256, srcbranch, srcsubdir2 = 
> > > _extract_new_source(args.version, srctree, args.no_patch,
> > >   File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 
> > > 183, in _extract_new_source
> > > __run('git checkout %s' % rev)
> > >   File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 
> > > 170, in __run
> > > return _run(cmd, srctree)
> > >   File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 31, 
> > > in _run
> > > return bb.process.run('%s' % cmd, cwd=cwd)
> > >   File "/home/ubuntu/yocto/poky/bitbake/lib/bb/process.py", line 189, in 
> > > run
> > > raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
> > > bb.process.ExecutionError: Execution of 'git checkout 
> > > 2e68773dfca072cb81f219fc3b97ad34fe9d9f94' failed with exit code 128:
> > > fatal: reference is not a tree: 
> > > 2e68773dfca072cb81f219fc3b97ad34fe9d9f94
> > >
> > >
> > > During handling of the above exception, another exception occurred:
> > >
> > > Traceback 

Re: [yocto] # honister #systemd attempting to run script on boot...

[Monsees, Steven C (US) via lists.yoctoproject.org]

I have this working now…

Thanks Matt for spotting those honister config issues, that led led me to the 
heart of the problem…

Steve
From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, October 11, 2022 3:55 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] # honister #systemd attempting to run script on boot...

External Email Alert

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



I am trying to make use of system to run a test script at boot…
I can exercise my test_script/test_script.service manually using systemctl 
commands and it appears to work as expects.

I created a recipe based on this, it builds clean (no errors/warnings), but it 
doesn’t appear to set things up correctly.
I have only recently begun working with honister, and new to systemd…

Could someone have look at my recipe & service file and see if they can spot 
anything ?

My recipe:

#
# This file is the my_test_script recipe.
#

SUMMARY = "Simple my_test_script application"
SECTION = "apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

inherit systemd

SRC_URI = "file://test_script.sh \
   file://test_script.service"

S = "${WORKDIR}"

SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE_${PN} = "test_script.service"
SYSTEMD_AUTO_ENABLE:${PN} = "enable"

do_install() {
 install -d ${D}${bindir}
 install -m 0755 ${S}/test_script.sh ${D}${bindir}

 install -d ${D}${systemd_system_unitdir}
 install -m 0644 ${S}/test_script.service 
${D}${systemd_system_unitdir}
}

FILES_${PN} = "${bindir}"
FILES_${PN} += "${systemd_system_unitdir}"

REQUIRED_DISTRO_FEATURES="systemd"
---
My test script service file:

[Unit]
Description=Configure test

[Service]
Type=oneshot
ExecStart=/usr/bin/test_script.sh start
StandardOutput=journal+console

[Install]
WantedBy=multi-user.target
---
My test script:

#!/bin/bash
# description: Description comes here

echo "***"
echo "START: Hello PetaLinux World :)"
date +"%m/%d/%Y %H:%M:%S $HOSTNAME"
echo "***"

Thanks,
Steve

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

[yocto] # honister #systemd attempting to run script on boot...

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am trying to make use of system to run a test script at boot...
I can exercise my test_script/test_script.service manually using systemctl 
commands and it appears to work as expects.

I created a recipe based on this, it builds clean (no errors/warnings), but it 
doesn't appear to set things up correctly.
I have only recently begun working with honister, and new to systemd...

Could someone have look at my recipe & service file and see if they can spot 
anything ?

My recipe:

#
# This file is the my_test_script recipe.
#

SUMMARY = "Simple my_test_script application"
SECTION = "apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

inherit systemd

SRC_URI = "file://test_script.sh \
   file://test_script.service"

S = "${WORKDIR}"

SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE_${PN} = "test_script.service"
SYSTEMD_AUTO_ENABLE:${PN} = "enable"

do_install() {
 install -d ${D}${bindir}
 install -m 0755 ${S}/test_script.sh ${D}${bindir}

 install -d ${D}${systemd_system_unitdir}
 install -m 0644 ${S}/test_script.service 
${D}${systemd_system_unitdir}
}

FILES_${PN} = "${bindir}"
FILES_${PN} += "${systemd_system_unitdir}"

REQUIRED_DISTRO_FEATURES="systemd"
---
My test script service file:

[Unit]
Description=Configure test

[Service]
Type=oneshot
ExecStart=/usr/bin/test_script.sh start
StandardOutput=journal+console

[Install]
WantedBy=multi-user.target
---
My test script:

#!/bin/bash
# description: Description comes here

echo "***"
echo "START: Hello PetaLinux World :)"
date +"%m/%d/%Y %H:%M:%S $HOSTNAME"
echo "***"

Thanks,
Steve

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

Re: [yocto] #yocto #dunfell

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks... will give it a try.

From: Ross Burton 
Sent: Tuesday, September 20, 2022 11:38 AM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #dunfell

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


Hi,

SBSA is EDK2 based, which is basically incredibly painful to patch.  The source 
files are windows-style CR/LF so your patch needs to have CR/LF, but if the 
whole patch has CR/LF then git "helpfully" transforms the patch to just 
unix-style LF, which doesn't apply.

The "solution" (workaround) is to convert the patch to LF encoding, and 
manually add the CR characters to the end of each line in the patch body.

The good news is that EDK2 is moving to LF encoding, so this will be solved at 
some point.

Ross


From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> 
mailto:yocto@lists.yoctoproject.org>> on behalf 
of Monsees, Steven C (US) via lists.yoctoproject.org 
mailto:steven.monsees=baesystems@lists.yoctoproject.org>>
Date: Tuesday, 20 September 2022 at 16:05
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>, 
yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> 
mailto:yocto@lists.yoctoproject.org>>
Subject: Re: [yocto] #yocto #dunfell

Any hints or ideas on what I might be doing wrong would be appreciated...

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Monday, September 19, 2022 2:22 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto #dunfell

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



I am seeing an error when I attempt to apply a patch, and could use some 
clarification or way to resolve...

Am doing something wrong in patch creation ?
What is meant by :  "Patch console.patch does not apply (enforce with -f)" ?
How can I best resolve this issue ?

I edited a file in the recipe's git repo in order to create the patch for the 
change:

git diff -u console.c

which I used as my patch:

diff --git a/lib/console.c b/lib/console.c
index 9c10560..b932a44 100644
--- a/lib/console.c
+++ b/lib/console.c
@@ -357,7 +357,7 @@ static struct {
{  EFI_SECURITY_VIOLATION, L"Security Violation"},

// warnings
-   {  EFI_WARN_UNKOWN_GLYPH,  L"Warning Unknown Glyph"},
+   {  EFI_WARN_UNKNOWN_GLYPH, L"Warning Unknown Glyph"},
{  EFI_WARN_DELETE_FAILURE,L"Warning Delete Failure"},
{  EFI_WARN_WRITE_FAILURE, L"Warning Write Failure"},
{  EFI_WARN_BUFFER_TOO_SMALL,  L"Warning Buffer Too Small"},

I am getting the following error when the patch is applied:

ERROR: efitools-native-1.7.0+gitAUTOINC+0649468475-r0 do_patch: Applying patch 
'console.patch' on target directory 
'/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/git'
Command Error: 'quilt --quiltrc 
/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/recipe-sysroot-native/etc/quiltrc
 push' exited with 0  Output:
Applying patch console.patch
patching file lib/console.c
Hunk #1 FAILED at 357.
1 out of 1 hunk FAILED -- rejects in file lib/console.c
Patch console.patch does not apply (enforce with -f)
ERROR: Logfile of failure stored in: 
/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/temp/log.do_patch.7615
ERROR: Task 
(/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/meta-bae/meta-limws/meta-intel/meta-sbca/recipes-bsp/efitools/efitools-native_git.bb:do_patch)
 failed with exit code '1'

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58097): https://lists.yoctoproject.org/g/yocto/message/58097
Mute This Topic: https://lists.yoctoproject.org/mt/93787499/21656
Mute #yocto:https://list

Re: [yocto] #yocto #dunfell

[Monsees, Steven C (US) via lists.yoctoproject.org]

Any hints or ideas on what I might be doing wrong would be appreciated…

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Monday, September 19, 2022 2:22 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] #yocto #dunfell

External Email Alert

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



I am seeing an error when I attempt to apply a patch, and could use some 
clarification or way to resolve…

Am doing something wrong in patch creation ?
What is meant by :  ”Patch console.patch does not apply (enforce with -f)” ?
How can I best resolve this issue ?

I edited a file in the recipe’s git repo in order to create the patch for the 
change:

git diff -u console.c

which I used as my patch:

diff --git a/lib/console.c b/lib/console.c
index 9c10560..b932a44 100644
--- a/lib/console.c
+++ b/lib/console.c
@@ -357,7 +357,7 @@ static struct {
{  EFI_SECURITY_VIOLATION, L"Security Violation"},

// warnings
-   {  EFI_WARN_UNKOWN_GLYPH,  L"Warning Unknown Glyph"},
+   {  EFI_WARN_UNKNOWN_GLYPH, L"Warning Unknown Glyph"},
{  EFI_WARN_DELETE_FAILURE,L"Warning Delete Failure"},
{  EFI_WARN_WRITE_FAILURE, L"Warning Write Failure"},
{  EFI_WARN_BUFFER_TOO_SMALL,  L"Warning Buffer Too Small"},

I am getting the following error when the patch is applied:

ERROR: efitools-native-1.7.0+gitAUTOINC+0649468475-r0 do_patch: Applying patch 
'console.patch' on target directory 
'/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/git'
Command Error: 'quilt --quiltrc 
/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/recipe-sysroot-native/etc/quiltrc
 push' exited with 0  Output:
Applying patch console.patch
patching file lib/console.c
Hunk #1 FAILED at 357.
1 out of 1 hunk FAILED -- rejects in file lib/console.c
Patch console.patch does not apply (enforce with -f)
ERROR: Logfile of failure stored in: 
/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/temp/log.do_patch.7615
ERROR: Task 
(/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/meta-bae/meta-limws/meta-intel/meta-sbca/recipes-bsp/efitools/efitools-native_git.bb:do_patch)
 failed with exit code '1'

Thanks,
Steve

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

[yocto] #yocto #dunfell

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am seeing an error when I attempt to apply a patch, and could use some 
clarification or way to resolve...

Am doing something wrong in patch creation ?
What is meant by :  "Patch console.patch does not apply (enforce with -f)" ?
How can I best resolve this issue ?

I edited a file in the recipe's git repo in order to create the patch for the 
change:

git diff -u console.c

which I used as my patch:

diff --git a/lib/console.c b/lib/console.c
index 9c10560..b932a44 100644
--- a/lib/console.c
+++ b/lib/console.c
@@ -357,7 +357,7 @@ static struct {
{  EFI_SECURITY_VIOLATION, L"Security Violation"},
// warnings
-   {  EFI_WARN_UNKOWN_GLYPH,  L"Warning Unknown Glyph"},
+   {  EFI_WARN_UNKNOWN_GLYPH, L"Warning Unknown Glyph"},
{  EFI_WARN_DELETE_FAILURE,L"Warning Delete Failure"},
{  EFI_WARN_WRITE_FAILURE, L"Warning Write Failure"},
{  EFI_WARN_BUFFER_TOO_SMALL,  L"Warning Buffer Too Small"},

I am getting the following error when the patch is applied:

ERROR: efitools-native-1.7.0+gitAUTOINC+0649468475-r0 do_patch: Applying patch 
'console.patch' on target directory 
'/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/git'
Command Error: 'quilt --quiltrc 
/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/recipe-sysroot-native/etc/quiltrc
 push' exited with 0  Output:
Applying patch console.patch
patching file lib/console.c
Hunk #1 FAILED at 357.
1 out of 1 hunk FAILED -- rejects in file lib/console.c
Patch console.patch does not apply (enforce with -f)
ERROR: Logfile of failure stored in: 
/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/builds/sbca-default/tmp/work/x86_64-linux/efitools-native/1.7.0+gitAUTOINC+0649468475-r0/temp/log.do_patch.7615
ERROR: Task 
(/disk0/scratch/yocto/workspace/poky-dunfell-23.0.19/meta-bae/meta-limws/meta-intel/meta-sbca/recipes-bsp/efitools/efitools-native_git.bb:do_patch)
 failed with exit code '1'

Thanks,
Steve

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

Re: [yocto] #yocto #dunfell #qemux86-64

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thank you, and I am looking at kirkstone...

-Original Message-
From: Khem Raj  
Sent: Wednesday, August 31, 2022 12:38 PM
To: Monsees, Steven C (US) ; Alexander Kanavin 

Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

On 8/31/22 4:36 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
> 
> Thank you for the quick replay...
> 
> The no graphic option does work but the kernel comes up with errors...
> 
> Will full wayland support be added to the dunfell release ?
> 

you can use vnc backend which is enabled by default. by using runqemu publicvnc

I wish runqemu was smart enough to prioritize, interactive UI e.g. 
sdl/gtk if not available then fall back to vnc, and then use nographic in order.

and please look at kirkstone if you are evaluating next LTS, dunfell is still 
supported but is already inching towards its end comparatively you get more 
modern package versions with kirkstone.

> Steve
> 
> -Original Message-
> From: yocto@lists.yoctoproject.org  On 
> Behalf Of Alexander Kanavin
> Sent: Wednesday, August 31, 2022 7:23 AM
> To: Monsees, Steven C (US) 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #yocto #dunfell #qemux86-64
> 
> External Email Alert
> 
> This email has been sent from an account outside of the BAE Systems network.
> 
> Please treat the email with caution, especially if you are requested to click 
> on a link, decrypt/open an attachment, or enable macros.  For further 
> information on how to spot phishing, access “Cybersecurity OneSpace Page” and 
> report phishing by clicking the button “Report Phishing” on the Outlook 
> toolbar.
> 
> 
> You need to run this in a X11 session, or use 'nographic' parameter.
> 
> Alex
> 
> On Wed, 31 Aug 2022 at 13:17, Monsees, Steven C (US) via 
> lists.yoctoproject.org  
> wrote:
>>
>>
>>
>> Hello:
>>
>>
>>
>> I am attempting to evaluate dunfell -23.0.17, on a cetos7 linux box.
>>
>>
>>
>> When building the default : core-image-minimal or core-image-sato, 
>> clean with no errors/warnings, on execution
>>
>> I get the following error for both (see below)…
>>
>>
>>
>> (1)Is this an issue with the release ?,  and is there another release I 
>> should be using ?
>>
>> (2)Is there something I need to pre-configure for these builds to run 
>> properly ?
>>
>> (3)How might I resolve this issue ?
>>
>>
>>
>> 06:57 smonsees@yix490016
>> /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunf
>> e
>> ll_Min>runqemu qemux86-64
>>
>> runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...
>>
>> runqemu - INFO - Continuing with the following parameters:
>>
>> KERNEL:
>> [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dun
>> f 
>> ell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fec
>> b 08507_85f0668fea-r0-qemux86-64-20220830151817.bin]
>>
>> MACHINE: [qemux86-64]
>>
>> FSTYPE: [ext4]
>>
>> ROOTFS:
>> [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dun
>> f
>> ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20
>> 2
>> 20830151817.rootfs.ext4]
>>
>> CONFFILE:
>> [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dun
>> f
>> ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20
>> 2
>> 20830151817.qemuboot.conf]
>>
>>
>>
>> runqemu - INFO - Setting up tap interface under sudo
>>
>> [sudo] password for smonsees:
>>
>> runqemu - INFO - Network configuration:
>> ip=192.168.7.2::192.168.7.1:255.255.255.0
>>
>> runqemu - INFO - Running 
>> /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64
>>  -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev 
>> tap,id=net0,ifname=tap0,script=no,downscript=no -drive 
>> file=/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.rootfs.ext4,if=virtio,format=raw
>>  -show-cursor -usb -device usb-tablet -object 
>> rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0   
>> -cpu core2duo -m 256 -serial mon:vc -serial null -kernel 
>> /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-2022083015181

Re: [yocto] #yocto #dunfell #qemux86-64

[Monsees, Steven C (US) via lists.yoctoproject.org]

I will have to double check, but the issue did not appear under zeus... 
so qemu changed sometime after zeus ?

-Original Message-
From: Alexander Kanavin  
Sent: Wednesday, August 31, 2022 8:12 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

External Email Alert

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

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


The issue is on your side, not on yocto's. By default qemu is configured to 
show graphical output in a X11 window, so you need to run it in a X11 session, 
with correctly set DISPLAY environment variable.

Alex

On Wed, 31 Aug 2022 at 14:10, Monsees, Steven C (US) 
 wrote:
>
>
> One final question, does this issue exist in kirkstone-4.0.2 ?
>
> Thanks,
> Steve
>
> -Original Message-
> From: Alexander Kanavin 
> Sent: Wednesday, August 31, 2022 7:42 AM
> To: Monsees, Steven C (US) 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #yocto #dunfell #qemux86-64
>
> External Email Alert
>
> This email has been sent from an account outside of the BAE Systems network.
>
> Please treat the email with caution, especially if you are requested to click 
> on a link, decrypt/open an attachment, or enable macros.  For further 
> information on how to spot phishing, access “Cybersecurity OneSpace Page” and 
> report phishing by clicking the button “Report Phishing” on the Outlook 
> toolbar.
>
>
> I need to see the errors to give a useful answer. If you want wayland, use 
> core-image-weston as the image.
>
> Alex
>
> On Wed, 31 Aug 2022 at 13:37, Monsees, Steven C (US) via 
> lists.yoctoproject.org  
> wrote:
> >
> >
> > Thank you for the quick replay...
> >
> > The no graphic option does work but the kernel comes up with errors...
> >
> > Will full wayland support be added to the dunfell release ?
> >
> > Steve
> >
> > -Original Message-
> > From: yocto@lists.yoctoproject.org  On 
> > Behalf Of Alexander Kanavin
> > Sent: Wednesday, August 31, 2022 7:23 AM
> > To: Monsees, Steven C (US) 
> > Cc: yocto@lists.yoctoproject.org
> > Subject: Re: [yocto] #yocto #dunfell #qemux86-64
> >
> > External Email Alert
> >
> > This email has been sent from an account outside of the BAE Systems network.
> >
> > Please treat the email with caution, especially if you are requested to 
> > click on a link, decrypt/open an attachment, or enable macros.  For further 
> > information on how to spot phishing, access “Cybersecurity OneSpace Page” 
> > and report phishing by clicking the button “Report Phishing” on the Outlook 
> > toolbar.
> >
> >
> > You need to run this in a X11 session, or use 'nographic' parameter.
> >
> > Alex
> >
> > On Wed, 31 Aug 2022 at 13:17, Monsees, Steven C (US) via 
> > lists.yoctoproject.org 
> >  wrote:
> > >
> > >
> > >
> > > Hello:
> > >
> > >
> > >
> > > I am attempting to evaluate dunfell -23.0.17, on a cetos7 linux box.
> > >
> > >
> > >
> > > When building the default : core-image-minimal or core-image-sato, 
> > > clean with no errors/warnings, on execution
> > >
> > > I get the following error for both (see below)…
> > >
> > >
> > >
> > > (1)Is this an issue with the release ?,  and is there another release 
> > > I should be using ?
> > >
> > > (2)Is there something I need to pre-configure for these builds to run 
> > > properly ?
> > >
> > > (3)How might I resolve this issue ?
> > >
> > >
> > >
> > > 06:57 smonsees@yix490016
> > > /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/d
> > > un
> > > fe
> > > ll_Min>runqemu qemux86-64
> > >
> > > runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...
> > >
> > > runqemu - INFO - Continuing with the following parameters:
> > >
> > > KERNEL:
> > > [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/
> > > du
> > > nf
> > > ell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3
> > > fe cb 08507_85f0668fea-r0-qemux86-64-20220830151817.bin]
> >

Re: [yocto] #yocto #dunfell #qemux86-64

[Monsees, Steven C (US) via lists.yoctoproject.org]

One final question, does this issue exist in kirkstone-4.0.2 ?

Thanks,
Steve

-Original Message-
From: Alexander Kanavin  
Sent: Wednesday, August 31, 2022 7:42 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

External Email Alert

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

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


I need to see the errors to give a useful answer. If you want wayland, use 
core-image-weston as the image.

Alex

On Wed, 31 Aug 2022 at 13:37, Monsees, Steven C (US) via lists.yoctoproject.org 
 wrote:
>
>
> Thank you for the quick replay...
>
> The no graphic option does work but the kernel comes up with errors...
>
> Will full wayland support be added to the dunfell release ?
>
> Steve
>
> -Original Message-
> From: yocto@lists.yoctoproject.org  On 
> Behalf Of Alexander Kanavin
> Sent: Wednesday, August 31, 2022 7:23 AM
> To: Monsees, Steven C (US) 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #yocto #dunfell #qemux86-64
>
> External Email Alert
>
> This email has been sent from an account outside of the BAE Systems network.
>
> Please treat the email with caution, especially if you are requested to click 
> on a link, decrypt/open an attachment, or enable macros.  For further 
> information on how to spot phishing, access “Cybersecurity OneSpace Page” and 
> report phishing by clicking the button “Report Phishing” on the Outlook 
> toolbar.
>
>
> You need to run this in a X11 session, or use 'nographic' parameter.
>
> Alex
>
> On Wed, 31 Aug 2022 at 13:17, Monsees, Steven C (US) via 
> lists.yoctoproject.org  
> wrote:
> >
> >
> >
> > Hello:
> >
> >
> >
> > I am attempting to evaluate dunfell -23.0.17, on a cetos7 linux box.
> >
> >
> >
> > When building the default : core-image-minimal or core-image-sato, 
> > clean with no errors/warnings, on execution
> >
> > I get the following error for both (see below)…
> >
> >
> >
> > (1)Is this an issue with the release ?,  and is there another release I 
> > should be using ?
> >
> > (2)Is there something I need to pre-configure for these builds to run 
> > properly ?
> >
> > (3)How might I resolve this issue ?
> >
> >
> >
> > 06:57 smonsees@yix490016
> > /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dun
> > fe
> > ll_Min>runqemu qemux86-64
> >
> > runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...
> >
> > runqemu - INFO - Continuing with the following parameters:
> >
> > KERNEL:
> > [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/du
> > nf 
> > ell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fe
> > cb 08507_85f0668fea-r0-qemux86-64-20220830151817.bin]
> >
> > MACHINE: [qemux86-64]
> >
> > FSTYPE: [ext4]
> >
> > ROOTFS:
> > [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/du
> > nf
> > ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-2
> > 02
> > 20830151817.rootfs.ext4]
> >
> > CONFFILE:
> > [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/du
> > nf
> > ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-2
> > 02
> > 20830151817.qemuboot.conf]
> >
> >
> >
> > runqemu - INFO - Setting up tap interface under sudo
> >
> > [sudo] password for smonsees:
> >
> > runqemu - INFO - Network configuration:
> > ip=192.168.7.2::192.168.7.1:255.255.255.0
> >
> > runqemu - INFO - Running 
> > /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64
> >  -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev 
> > tap,id=net0,ifname=tap0,script=no,downscript=no -drive 
> > file=/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.rootfs.ext4,if=virtio,format=raw
> >  -show-cursor -usb -device usb-tablet -object 
> > rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0   
> > -cpu core2duo -m 256 -serial

Re: [yocto] #yocto #dunfell #qemux86-64

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thank you for the quick replay...

The no graphic option does work but the kernel comes up with errors...

Will full wayland support be added to the dunfell release ?

Steve

-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Alexander Kanavin
Sent: Wednesday, August 31, 2022 7:23 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

External Email Alert

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

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


You need to run this in a X11 session, or use 'nographic' parameter.

Alex

On Wed, 31 Aug 2022 at 13:17, Monsees, Steven C (US) via lists.yoctoproject.org 
 wrote:
>
>
>
> Hello:
>
>
>
> I am attempting to evaluate dunfell -23.0.17, on a cetos7 linux box.
>
>
>
> When building the default : core-image-minimal or core-image-sato, 
> clean with no errors/warnings, on execution
>
> I get the following error for both (see below)…
>
>
>
> (1)Is this an issue with the release ?,  and is there another release I 
> should be using ?
>
> (2)Is there something I need to pre-configure for these builds to run 
> properly ?
>
> (3)How might I resolve this issue ?
>
>
>
> 06:57 smonsees@yix490016 
> /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfe
> ll_Min>runqemu qemux86-64
>
> runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...
>
> runqemu - INFO - Continuing with the following parameters:
>
> KERNEL: 
> [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunf
> ell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb
> 08507_85f0668fea-r0-qemux86-64-20220830151817.bin]
>
> MACHINE: [qemux86-64]
>
> FSTYPE: [ext4]
>
> ROOTFS: 
> [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunf
> ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-202
> 20830151817.rootfs.ext4]
>
> CONFFILE: 
> [/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunf
> ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-202
> 20830151817.qemuboot.conf]
>
>
>
> runqemu - INFO - Setting up tap interface under sudo
>
> [sudo] password for smonsees:
>
> runqemu - INFO - Network configuration: 
> ip=192.168.7.2::192.168.7.1:255.255.255.0
>
> runqemu - INFO - Running 
> /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64
>  -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev 
> tap,id=net0,ifname=tap0,script=no,downscript=no -drive 
> file=/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.rootfs.ext4,if=virtio,format=raw
>  -show-cursor -usb -device usb-tablet -object 
> rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0   
> -cpu core2duo -m 256 -serial mon:vc -serial null -kernel 
> /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-20220830151817.bin
>  -append 'root=/dev/vda rw  mem=256M 
> ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 '
>
>
>
> runqemu - ERROR - Failed to run qemu: Could not initialize SDL(x11 not 
> available) - exiting
>
>
>
> runqemu - INFO - Cleaning up
>
> Set 'tap0' nonpersistent
>
>
>
> Thank you for your help,
>
> Steve
>
>
>
>
> 
>

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

[yocto] #yocto #dunfell #qemux86-64

[Monsees, Steven C (US) via lists.yoctoproject.org]

Hello:

I am attempting to evaluate dunfell -23.0.17, on a cetos7 linux box.

When building the default : core-image-minimal or core-image-sato, clean with 
no errors/warnings, on execution
I get the following error for both (see below)...


(1)Is this an issue with the release ?,  and is there another release I 
should be using ?

(2)Is there something I need to pre-configure for these builds to run 
properly ?

(3)How might I resolve this issue ?

06:57 smonsees@yix490016 
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min>runqemu
 qemux86-64
runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...
runqemu - INFO - Continuing with the following parameters:
KERNEL: 
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-20220830151817.bin]
MACHINE: [qemux86-64]
FSTYPE: [ext4]
ROOTFS: 
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.rootfs.ext4]
CONFFILE: 
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.qemuboot.conf]

runqemu - INFO - Setting up tap interface under sudo
[sudo] password for smonsees:
runqemu - INFO - Network configuration: 
ip=192.168.7.2::192.168.7.1:255.255.255.0
runqemu - INFO - Running 
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64
 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev 
tap,id=net0,ifname=tap0,script=no,downscript=no -drive 
file=/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.rootfs.ext4,if=virtio,format=raw
 -show-cursor -usb -device usb-tablet -object 
rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0   -cpu 
core2duo -m 256 -serial mon:vc -serial null -kernel 
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-20220830151817.bin
 -append 'root=/dev/vda rw  mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 
oprofile.timer=1 '

runqemu - ERROR - Failed to run qemu: Could not initialize SDL(x11 not 
available) - exiting

runqemu - INFO - Cleaning up
Set 'tap0' nonpersistent

Thank you for your help,
Steve


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

[yocto] #kirkstone qemu

[Monsees, Steven C (US) via lists.yoctoproject.org]

Hello:

I built kirkstone core-image-sato from scratch no modifications, clean build 
was going test kirkstone out...
When I went to run using qemu I saw the following issue with "tun", even after 
a manual tun config I still got another qemu error (see below):


(1)Is this a known issue and how would I build in proper "tun" support for 
the core-image-sato/qemu  ?

(2)How would I run "runqemu-gen-tapdevs" to manually create one for testing 
?

[yocto_user@9d7e1015e117 poky-kirkstone-4.0.2]$ ls
bitbakekirkstone2MAINTAINERS.md  meta-poky   
oe-init-build-env   README.poky.md
contribLICENSE   Makefilemeta-selftest   
README.hardware.md  README.qemu.md
documentation  LICENSE.GPL-2.0-only  MEMORIAMmeta-skeleton   README.md  
 scripts
kirkstone1 LICENSE.MIT   metameta-yocto-bsp  
README.OE-Core.md
[yocto_user@9d7e1015e117 poky-kirkstone-4.0.2]$ source oe-init-build-env 
kirkstone2
You had no conf/bblayers.conf file. This configuration file has therefore been
created for you with some default values. To add additional metadata layers
into your configuration please add entries to conf/bblayers.conf.

The Yocto Project has extensive documentation about OE including a reference
manual which can be found at:
https://docs.yoctoproject.org

For more information about OpenEmbedded see the website:
https://www.openembedded.org/


### Shell environment set up for builds. ###

You can now run 'bitbake '

Common targets are:
core-image-minimal
core-image-full-cmdline
core-image-sato
core-image-weston
meta-toolchain
meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

Other commonly useful commands are:
- 'devtool' and 'recipetool' handle common recipe tasks
- 'bitbake-layers' handles common layer tasks
- 'oe-pkgdata-util' handles common target package tasks
[yocto_user@9d7e1015e117 kirkstone2]$ bitbake -k core-image-sato
Loading cache: 100% |   
| ETA:  --:--:--
Loaded 0 entries from dependency cache.
Parsing recipes: 100% 
|##|
 Time: 0:00:49
Parsing of 882 .bb files complete (0 cached, 882 parsed). 1641 targets, 44 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "2.0.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "centos-7"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "qemux86-64"
DISTRO   = "poky"
DISTRO_VERSION   = "4.0.2"
TUNE_FEATURES= "m64 core2"
TARGET_FPU   = ""
meta
meta-poky
meta-yocto-bsp   = ":"

Initialising tasks: 100% 
|###|
 Time: 0:00:05
Sstate summary: Wanted 2730 Local 2722 Mirrors 5 Missed 3 Current 0 (99% match, 
0% complete)
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 6556 tasks of which 6543 didn't need to be rerun 
and all succeeded.
[yocto_user@9d7e1015e117 kirkstone2]$ runqemu qemux86-64
runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...
runqemu - ERROR - TUN control device /dev/net/tun is unavailable; you may need 
to enable TUN (e.g. sudo modprobe tun)
runqemu - INFO - Cleaning up
[yocto_user@9d7e1015e117 kirkstone2]$ lsmod |grep tun
tun36164  0
[yocto_user@9d7e1015e117 kirkstone2]$ sudo modprobe tun
[sudo] password :
[yocto_user@9d7e1015e117 kirkstone2]$ lsmod |grep tun
tun36164  0
[yocto_user@9d7e1015e117 kirkstone2]$ ls /dev
console  core  fd  full  mqueue  null  ptmx  pts  random  shm  stderr  stdin  
stdout  tty  urandom  zero
[yocto_user@9d7e1015e117 kirkstone2]$ mkdir -p /dev/net
mkdir: cannot create directory '/dev/net': Permission denied
[yocto_user@9d7e1015e117 kirkstone2]$ sudo mkdir -p /dev/net
[yocto_user@9d7e1015e117 kirkstone2]$ ls /dev
console  core  fd  full  mqueue  net  null  ptmx  pts  random  shm  stderr  
stdin  stdout  tty  urandom  zero
[yocto_user@9d7e1015e117 kirkstone2]$ sudo mknod /dev/net/tun c 10 200
[yocto_user@9d7e1015e117 kirkstone2]$ sudo chmod 0666 /dev/net/tun
[yocto_user@9d7e1015e117 kirkstone2]$ ls -l /dev/net/tun
crw-rw-rw-. 1 root root 10, 200 Aug 10 14:10 /dev/net/tun
[yocto_user@9d7e1015e117 kirkstone2]$ runqemu qemux86-64
runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...
runqemu - INFO - Continuing with the following parameters:
KERNEL: 
[/disk0/scratch/yocto_user/yocto/workspace_zeus/poky-kirkstone-4.0.2/kirkstone2/tmp/deploy/images/qemux86-64/bzImage--5.15.44+git0+947149960e_eb3df10e3f-r0-qemux86-64-20220809161004.bin]
MACHINE: [qemux86-64]
FSTYPE: [ext4]
ROOTFS: 

[yocto] poky-dunfell-23.0.17

[Monsees, Steven C (US) via lists.yoctoproject.org]

I wanted to do a simple test with dunfell, my system meets all the minimum 
requirements based on documentation, and I am running under centos7...

I downloaded poky-dunfell-23.0.17, built both "core-image-minimal" and 
"core-image-sato" with not build issues, but when I go to run "runqemu 
qemux86-64" I am getting the following error for both builds, can you explain 
why and how to to correct for this ?

11:07 smonsees@yix490093 
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/mdunfell>runqemu
 qemux86-64
runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...
runqemu - INFO - Continuing with the following parameters:
KERNEL: 
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/mdunfell/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-20220802141232.bin]
MACHINE: [qemux86-64]
FSTYPE: [ext4]
ROOTFS: 
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/mdunfell/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220802141232.rootfs.ext4]
CONFFILE: 
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/mdunfell/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220802141232.qemuboot.conf]

runqemu - INFO - Setting up tap interface under sudo
runqemu - INFO - Network configuration: 
ip=192.168.7.2::192.168.7.1:255.255.255.0
runqemu - INFO - Running 
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/mdunfell/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64
 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev 
tap,id=net0,ifname=tap0,script=no,downscript=no -drive 
file=/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/mdunfell/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220802141232.rootfs.ext4,if=virtio,format=raw
 -show-cursor -usb -device usb-tablet -object 
rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0   -cpu 
core2duo -m 256 -serial mon:vc -serial null -kernel 
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/mdunfell/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-20220802141232.bin
 -append 'root=/dev/vda rw  mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 
oprofile.timer=1 '

runqemu - ERROR - Failed to run qemu: X Error:  BadRequest
  Request Major code 130 (MIT-SHM)
  Request Minor code 1 ()
  Error Serial #124
  Current Serial #125

runqemu - INFO - Cleaning up
Set 'tap0' nonpersistent
11:07 smonsees@yix490093 
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/mdunfell>

Thanks,
Steve

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

Re: [yocto] enabling symbols for debug in clinfo

[Monsees, Steven C (US) via lists.yoctoproject.org]

I will need to test but, that appears to have done the trick...


root@sbcb-default gdb clinfo
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-poky-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from clinfo...
Reading symbols from /usr/bin/.debug/clinfo...
(gdb)

Thanks
Steve

-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Ross Burton
Sent: Monday, May 9, 2022 7:56 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] enabling symbols for debug in clinfo

External Email Alert

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

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


Unless clinfo is doing something wrong, it will be built with -g anyway.  
You’ll just need to install clinfo-dbg to get the symbols, as they’ll be split 
out into a separate package during packaging.

Ross

> On 9 May 2022, at 11:54, Monsees, Steven C (US) via lists.yoctoproject.org 
>  wrote:
>
>
> Hello:
>
> I’d like to build clinfo w/ “-g” option to do some debugging with GDB…
>
> I am looking at: 
> meta-openembedded/meta-oe/recipes-support/opencl/clinfo_2.2.18.04.06.b
> b
>
> I created a “bbapend” file to modify the build recipes “Makefile.am” file 
> prior to build, to introduce ‘-g’ for CFLAGS & CPPFLAGS, i.e. at top of 
> Makefile.am added:
>
> AM_CFLAGS - -g
> AM_CPPFLAGS = -g
>
> I checked the build tree and see my modified “Makefile.am” updated as 
> expected, the update occurs at the end of the install process, using 
> do_install_append… so the build should have used my modified file… but I do 
> not have symbols for the clinfo package when I go to use GDB.
>
> Is there a simple way to enable debug symbols for this package ?
>
> Did I modify the wrong configuration file?, Should I be modifying configure ?
>
> I am new to auto-build configurations… Could someone tell me the 
> easiest way to add “-g” to the clinfo standard build ?
>
> Thanks,
> Steve
>
> 

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

[yocto] enabling symbols for debug in clinfo

[Monsees, Steven C (US) via lists.yoctoproject.org]

Hello:

I'd like to build clinfo w/ "-g" option to do some debugging with GDB...

I am looking at: 
meta-openembedded/meta-oe/recipes-support/opencl/clinfo_2.2.18.04.06.bb

I created a "bbapend" file to modify the build recipes "Makefile.am" file prior 
to build, to introduce '-g' for CFLAGS & CPPFLAGS, i.e. at top of Makefile.am 
added:

AM_CFLAGS - -g
AM_CPPFLAGS = -g

I checked the build tree and see my modified "Makefile.am" updated as expected, 
the update occurs at the end of the install process, using do_install_append... 
so the build should have used my modified file... but I do not have symbols for 
the clinfo package when I go to use GDB.

Is there a simple way to enable debug symbols for this package ?

Did I modify the wrong configuration file?, Should I be modifying configure ?

I am new to auto-build configurations...
Could someone tell me the easiest way to add "-g" to the clinfo standard build ?

Thanks,
Steve

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

Re: [yocto] CVE patch updates

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks Tim,  subscribed…

From: Tim Orling 
Sent: Thursday, March 24, 2022 9:03 PM
To: Richard Purdie 
Cc: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] CVE patch updates

External Email Alert

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




On Thu, Mar 24, 2022 at 2:45 PM Richard Purdie 
mailto:richard.pur...@linuxfoundation.org>> 
wrote:
On Thu, 2022-03-24 at 16:56 +, Monsees, Steven C (US) via
lists.yoctoproject.org<http://lists.yoctoproject.org> wrote:
>
> I am currently building in cve-check to see what is reported, and I was 
> curious
> if Yocto might provide any CVE based patch repositories ?
>
> Is there a yocto page somewhere that goes over this side of things ?,
> I did not see much in the mega-manual… I am running on zeus based platforms 
> (for
> both armarch64 and x86_64).
>

You'll see output of cve-check on the yocto-security list for layers that are
still in maintenance:

https://lists.yoctoproject.org/g/yocto-security/messages

although zeus is out of maintenance.

We merge CVE fixes to the branches that are in maintenance.

A graph showing the data over time:

https://docs.google.com/spreadsheets/d/e/2PACX-1vRgNISmH0Ditf0bRtSezeR2XsgKIiSFJKF6KJUHpnzocNGzvKZbuSDKfmV3n64BFXDRqElBSJnhHtG4/pubchart?oid=1993375488=interactive

Steven, if you haven’t already, you should subscribe to
https://lists.yoctoproject.org/g/yocto-security

Emails are sent out, usually on Sunday. If you see a CVE that interests you… 
grab it and fix it.

This is mostly a community effort. There is no special dedicated squad of 
security champions.


Cheers,

Richard






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

Re: [yocto] CVE patch updates

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks Richard, will do…

From: Tim Orling 
Sent: Thursday, March 24, 2022 9:03 PM
To: Richard Purdie 
Cc: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] CVE patch updates

External Email Alert

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




On Thu, Mar 24, 2022 at 2:45 PM Richard Purdie 
mailto:richard.pur...@linuxfoundation.org>> 
wrote:
On Thu, 2022-03-24 at 16:56 +, Monsees, Steven C (US) via
lists.yoctoproject.org<http://lists.yoctoproject.org> wrote:
>
> I am currently building in cve-check to see what is reported, and I was 
> curious
> if Yocto might provide any CVE based patch repositories ?
>
> Is there a yocto page somewhere that goes over this side of things ?,
> I did not see much in the mega-manual… I am running on zeus based platforms 
> (for
> both armarch64 and x86_64).
>

You'll see output of cve-check on the yocto-security list for layers that are
still in maintenance:

https://lists.yoctoproject.org/g/yocto-security/messages

although zeus is out of maintenance.

We merge CVE fixes to the branches that are in maintenance.

A graph showing the data over time:

https://docs.google.com/spreadsheets/d/e/2PACX-1vRgNISmH0Ditf0bRtSezeR2XsgKIiSFJKF6KJUHpnzocNGzvKZbuSDKfmV3n64BFXDRqElBSJnhHtG4/pubchart?oid=1993375488=interactive

Steven, if you haven’t already, you should subscribe to
https://lists.yoctoproject.org/g/yocto-security

Emails are sent out, usually on Sunday. If you see a CVE that interests you… 
grab it and fix it.

This is mostly a community effort. There is no special dedicated squad of 
security champions.


Cheers,

Richard






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

Re: [yocto] CVE patch updates

[Monsees, Steven C (US) via lists.yoctoproject.org]

/yocto/workspace_1/poky/meta/recipes-core/meta/cve-update-db-native.bb:do_populate_cve_db
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
14:41 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default>find . -name 
'_ssl.c' -print
14:47 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default>



From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, March 24, 2022 2:00 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] CVE patch updates

External Email Alert

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



When building in cve-check to see what is reported, it generated all 
blank/empty report files…
Can someone explain this ?, my local.conf does have the proper modification 
(INHERIT += “cve-check”).


10:55 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default> bitbake -k 
sbca-defaultfs-full
Parsing recipes: 100% 
|#|
 Time: 0:01:07
Parsing of 2555 .bb files complete (0 cached, 2555 parsed). 3769 targets, 96 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.44.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "rhel-7.9"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "sbca-default"
DISTRO   = "limws"
DISTRO_VERSION   = "3.0.4"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta
meta-poky= "my_yocto_3.0.4:2f9bca440204f9e73158705a4ec04698b1f6ad42"
meta-perl
meta-python
meta-filesystems
meta-networking
meta-initramfs
meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-virtualization  = "zeus:7e5219669ff6f8e9c8c33ffd230e95a6b2b025f4"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-clang   = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel   = 
"LIMWSSWARE-682-oews-meta-bae-clean-up:99f116056452f1fefe83fe458f533b48f52fe4ba"

Initialising tasks: 100% 
|##|
 Time: 0:00:04
Checking sstate mirror object availability: 100% 
|##| Time: 
0:00:02
Sstate summary: Wanted 2258 Found 15 Missed 2243 Current 0 (0% match, 0% 
complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
Image CVE report stored in: 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/core-image-minimal-initramfs-sbca-default-20220324145629.rootfs.cve
Image CVE report stored in: 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/aiox_orange-sbca-default-20220324145629.rootfs.cve
NOTE: Tasks Summary: Attempted 6753 tasks of which 77 didn't need to be rerun 
and all succeeded.


13:33 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default>ls -l 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/core-image-minimal-initramfs-sbca-default-20220324145629.rootfs.cve
-rw-r--r--. 1 smonsees none 0 Mar 24 13:16 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/core-image-minimal-initramfs-sbca-default-20220324145629.rootfs.cve
13:33 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default>ls -l 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/aiox_orange-sbca-default-20220324145629.rootfs.cve
-rw-r--r--. 1 smonsees none 0 Mar 24 13:17 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/aiox_orange-sbca-default-20220324145629.rootfs.cve
13:33 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default>


13:27 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/cve>ls
 -l
total 0
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 binutils
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:06 binutils-cross-x86_64
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 binutils-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 bluez5
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:12 boost
-rw-rw-r--. 1 

Re: [yocto] CVE patch updates

[Monsees, Steven C (US) via lists.yoctoproject.org]

When building in cve-check to see what is reported, it generated all 
blank/empty report files...
Can someone explain this ?, my local.conf does have the proper modification 
(INHERIT += "cve-check").


10:55 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default> bitbake -k 
sbca-defaultfs-full
Parsing recipes: 100% 
|#|
 Time: 0:01:07
Parsing of 2555 .bb files complete (0 cached, 2555 parsed). 3769 targets, 96 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.44.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "rhel-7.9"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "sbca-default"
DISTRO   = "limws"
DISTRO_VERSION   = "3.0.4"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta
meta-poky= "my_yocto_3.0.4:2f9bca440204f9e73158705a4ec04698b1f6ad42"
meta-perl
meta-python
meta-filesystems
meta-networking
meta-initramfs
meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-virtualization  = "zeus:7e5219669ff6f8e9c8c33ffd230e95a6b2b025f4"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-clang   = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel   = 
"LIMWSSWARE-682-oews-meta-bae-clean-up:99f116056452f1fefe83fe458f533b48f52fe4ba"

Initialising tasks: 100% 
|##|
 Time: 0:00:04
Checking sstate mirror object availability: 100% 
|##| Time: 
0:00:02
Sstate summary: Wanted 2258 Found 15 Missed 2243 Current 0 (0% match, 0% 
complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
Image CVE report stored in: 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/core-image-minimal-initramfs-sbca-default-20220324145629.rootfs.cve
Image CVE report stored in: 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/aiox_orange-sbca-default-20220324145629.rootfs.cve
NOTE: Tasks Summary: Attempted 6753 tasks of which 77 didn't need to be rerun 
and all succeeded.


13:33 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default>ls -l 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/core-image-minimal-initramfs-sbca-default-20220324145629.rootfs.cve
-rw-r--r--. 1 smonsees none 0 Mar 24 13:16 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/core-image-minimal-initramfs-sbca-default-20220324145629.rootfs.cve
13:33 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default>ls -l 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/aiox_orange-sbca-default-20220324145629.rootfs.cve
-rw-r--r--. 1 smonsees none 0 Mar 24 13:17 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/images/sbca-default/aiox_orange-sbca-default-20220324145629.rootfs.cve
13:33 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default>


13:27 smonsees@yix465383 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbca-default/tmp/deploy/cve>ls
 -l
total 0
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 binutils
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:06 binutils-cross-x86_64
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 binutils-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 bluez5
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:12 boost
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 cairo
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:12 cairo-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:16 cpio-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 curl
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:05 curl-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:05 dbus
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:05 dbus-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:06 e2fsprogs
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:06 e2fsprogs-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:05 file-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 flex
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:06 flex-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:05 gcc-source-9.2.0
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:06 gettext-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:06 glib-2.0
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:05 glib-2.0-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:06 glibc
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 gnutls
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 go-cross-corei7-64
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 go-native
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:13 go-runtime
-rw-rw-r--. 1 smonsees none 0 Mar 24 13:12 

[yocto] CVE patch updates

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am currently building in cve-check to see what is reported, and I was curious 
if Yocto might provide any CVE based patch repositories ?

Is there a yocto page somewhere that goes over this side of things ?,
I did not see much in the mega-manual... I am running on zeus based platforms 
(for both armarch64 and x86_64).

Thanks,
Steve

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

Re: [yocto] configuration fragments

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks again...

-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Khem Raj
Sent: Tuesday, March 15, 2022 11:48 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] configuration fragments

External Email Alert

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

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


if you are using linux-yocto for kernel then it is surely supported , so as 
long as it is added to kernel recipe it should work ok.

On Tue, Mar 15, 2022 at 3:58 AM Monsees, Steven C (US) via 
lists.yoctoproject.org  
wrote:
>
>
> When you say:
>
> " you might have to look into this kernel recipe and ensure that it has 
> enabled merging configs feature from kernel"
>
> Are you talking about inheriting from "kernel-yocto" in order to work with 
> configuration fragments ?
>
> Thanks,
> Steve
>
> -Original Message-
> From: Khem Raj 
> Sent: Monday, March 14, 2022 4:13 PM
> To: Monsees, Steven C (US) 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] configuration fragments
>
> External Email Alert
>
> This email has been sent from an account outside of the BAE Systems network.
>
> Please treat the email with caution, especially if you are requested to click 
> on a link, decrypt/open an attachment, or enable macros.  For further 
> information on how to spot phishing, access “Cybersecurity OneSpace Page” and 
> report phishing by clicking the button “Report Phishing” on the Outlook 
> toolbar.
>
>
> On Mon, Mar 14, 2022 at 12:57 PM Monsees, Steven C (US) via 
> lists.yoctoproject.org  
> wrote:
> >
> >
> >
> > Under my aarm64 platform ../recipes-core/images I have a file 
> > “aiox-swdebugfs.inc”
> >
> >
> >
> > Which basically contains:
> >
> >
> >
> > EXTRAPATHS_prepend := "$(THISDIR}/files:"
> >
> > LIC_FILES_CHKSUM = 
> > "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
> >
> > SRC_URI += file://aiox-swdebugfs.cfg
> >
> >
> >
> > I include this in my aiox-swdebugfs.bb like so: “require aiox-swdebugfs.inc”
> >
> >
> >
> > It does not appear to apply my configuration fragments…
> >
> > (CONFIG_SCHED_TRACER, CONFIG_TRACER, etc. for additional perf 
> > support)
> >
> >
>
> these are some config files for doing what ? from what it looks like, this 
> inc file is adding a kernel config fragment if so then it should be appended 
> too kernel recipe so if aiox-swdebugfs.bb is kernel recipe then you are doing 
> it right, but then you might have to look into this kernel recipe and ensure 
> that it has enabled merging configs feature from kernel. Otherwise these cfgs 
> wont be processed.
>
> >
> > I have the exact same implementation working under my intel platform.
> >
> >
> >
> > Can someone tell me what I might be doing wrong, or how I can get my 
> > configuration fragments to be applied properly ?
> >
> > Any ideas why it might work properly under one architecture and not on the 
> > other ?
> >
> >
> >
> > Thanks,
> >
> > Steve
> >
> >
> >
> >
>
> 
>

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

Re: [yocto] configuration fragments

[Monsees, Steven C (US) via lists.yoctoproject.org]

When you say:

" you might have to look into this kernel recipe and ensure that it has enabled 
merging configs feature from kernel"

Are you talking about inheriting from "kernel-yocto" in order to work with 
configuration fragments ?

Thanks,
Steve

-Original Message-
From: Khem Raj  
Sent: Monday, March 14, 2022 4:13 PM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] configuration fragments

External Email Alert

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

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


On Mon, Mar 14, 2022 at 12:57 PM Monsees, Steven C (US) via 
lists.yoctoproject.org  
wrote:
>
>
>
> Under my aarm64 platform ../recipes-core/images I have a file 
> “aiox-swdebugfs.inc”
>
>
>
> Which basically contains:
>
>
>
> EXTRAPATHS_prepend := "$(THISDIR}/files:"
>
> LIC_FILES_CHKSUM = 
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>
> SRC_URI += file://aiox-swdebugfs.cfg
>
>
>
> I include this in my aiox-swdebugfs.bb like so: “require aiox-swdebugfs.inc”
>
>
>
> It does not appear to apply my configuration fragments…
>
> (CONFIG_SCHED_TRACER, CONFIG_TRACER, etc. for additional perf support)
>
>

these are some config files for doing what ? from what it looks like, this inc 
file is adding a kernel config fragment if so then it should be appended too 
kernel recipe so if aiox-swdebugfs.bb is kernel recipe then you are doing it 
right, but then you might have to look into this kernel recipe and ensure that 
it has enabled merging configs feature from kernel. Otherwise these cfgs wont 
be processed.

>
> I have the exact same implementation working under my intel platform.
>
>
>
> Can someone tell me what I might be doing wrong, or how I can get my 
> configuration fragments to be applied properly ?
>
> Any ideas why it might work properly under one architecture and not on the 
> other ?
>
>
>
> Thanks,
>
> Steve
>
>
> 
>

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

[yocto] configuration fragments

[Monsees, Steven C (US) via lists.yoctoproject.org]

Under my aarm64 platform ../recipes-core/images I have a file 
"aiox-swdebugfs.inc"

Which basically contains:

EXTRAPATHS_prepend := "$(THISDIR}/files:"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI += file://aiox-swdebugfs.cfg

I include this in my aiox-swdebugfs.bb like so: "require aiox-swdebugfs.inc"

It does not appear to apply my configuration fragments...
(CONFIG_SCHED_TRACER, CONFIG_TRACER, etc. for additional perf support)

I have the exact same implementation working under my intel platform.

Can someone tell me what I might be doing wrong, or how I can get my 
configuration fragments to be applied properly ?
Any ideas why it might work properly under one architecture and not on the 
other ?

Thanks,
Steve

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

[yocto] zeus intel preempt_rt config

[Monsees, Steven C (US) via lists.yoctoproject.org]

How do override/modify the kernel .config file generated when building for 
linux-intel-rt (PREEMPT_RT) ?

I dumped /proc/config.gz and it is always the default configuration my 
changes/updates are never included.

I do not seem to have this issue when building PREEMPT_RT for Xilinx/ARM ...

I am trying to add additional configuration for docker support (missing 
elements seen by /usr/share/docker/check-config.sh).

Thanks,
Steve

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

[yocto] Yocto Zeus -docker/PREEMPT_RT

[Monsees, Steven C (US) via lists.yoctoproject.org]

I have 2 platforms one with a standard kernel the other using PREEMPT_RT 
kernel... both work as expected.

All things being equal, when I add docker container support to both platforms, 
the standard kernel works just fine, but on the
PREEMPT_RT kernel docker does not appear to initialize/work correctly...

I have also tested using both ARM & Intel based HW, and appear tosee the same 
behavior on both.

Checking online it appears there is chatter about whether docker will run 
correctly under a PREEMPT_RT kernel.
Example:

Last entry, from July 2021, in this blog says not supported;
Docker for RTOS? - General Discussions / Feature Requests - Docker Community 
Forums

Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this 
combination supported ?

I am currently running zeus based platforms, docker is at version 19.03.2-ce.

Is there a patch to correct for the compatibility issues being seen ?, or
Is there a yocto version I might move to which supports both correctly ?

Any input on this would be greatly appreciated.

Thanks,
Steve



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

Re: [yocto] patching files under "dynamic-layers"

[Monsees, Steven C (US) via lists.yoctoproject.org]

Never mind was able to work this out…

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Monday, February 7, 2022 10:42 AM
To: yocto@lists.yoctoproject.org
Subject: [yocto] patching files under "dynamic-layers"

External Email Alert

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



I am building with zeus 3.0.4, Intel based…

I trying to learn how to introduce a patch to files brought in by packages 
under “dynamic –layers”… my bbappend appears not to be applying my test patch 
(even though no errors/warnings thrown)…

This is the package I am trying to manipulate:

/disk0/scratch/smonsees/yocto/workspace_3/meta-intel/dynamic-layers/clang-layer/recipes-opencl/igc
It contains:
files  intel-graphics-compiler_1.0.11.bb

This is my recipe to apply patch:

/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/dynamic-layers/clang-layer/recipes-opencl/igc
It contains:
files  intel-graphics-compiler_1.0.11.bbappend

files - contains the file I am attempting to patch (FILE_TO_PATCH.patch)
intel-graphics-compiler_1.0.11.bbappend is setup like so, where

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "\
file://FILE_TO_PATCH.patch \
"

I attempted to male use of BBFILES_DYNAMIC but even though I get no error, 
patch is not applied.

conf/layer.conf:
BBFILES_DYNAMIC += " \

clang-layer:$(LAYERDIR)/dynamic-layers/clang-layer/recipes-opencl/igc/*.bbappend
 \
"

Can you explain to me the proper way to patch files under these circumstances 
and where I went wrong ?

Thanks,
Steve


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

[yocto] patching files under "dynamic-layers"

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am building with zeus 3.0.4, Intel based...

I trying to learn how to introduce a patch to files brought in by packages 
under "dynamic -layers"... my bbappend appears not to be applying my test patch 
(even though no errors/warnings thrown)...

This is the package I am trying to manipulate:

/disk0/scratch/smonsees/yocto/workspace_3/meta-intel/dynamic-layers/clang-layer/recipes-opencl/igc
It contains:
files  intel-graphics-compiler_1.0.11.bb

This is my recipe to apply patch:

/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/dynamic-layers/clang-layer/recipes-opencl/igc
It contains:
files  intel-graphics-compiler_1.0.11.bbappend

files - contains the file I am attempting to patch (FILE_TO_PATCH.patch)
intel-graphics-compiler_1.0.11.bbappend is setup like so, where

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "\
file://FILE_TO_PATCH.patch \
"

I attempted to male use of BBFILES_DYNAMIC but even though I get no error, 
patch is not applied.

conf/layer.conf:
BBFILES_DYNAMIC += " \

clang-layer:$(LAYERDIR)/dynamic-layers/clang-layer/recipes-opencl/igc/*.bbappend
 \
"

Can you explain to me the proper way to patch files under these circumstances 
and where I went wrong ?

Thanks,
Steve


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

Re: [yocto] IGC build issue with devtoolset-8 (GNU 8.3.1)

[Monsees, Steven C (US) via lists.yoctoproject.org]

Is there a CPP conflict due to :

./tmp/work/corei7-64-poky-linux/intel-graphics-compiler/1.0.11-r0/git/inc/common/UFO/portable_compiler.h

Is this a name space issue ?

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, February 3, 2022 8:33 AM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] IGC build issue with devtoolset-8 (GNU 8.3.1)

External Email Alert

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



Anybody ?

It appears to be a CPP issue in the IGC code… but not sure why.
The “__syscall_slong_t” definition appears to be getting resolved out correctly 
when I replace the array with individual variables of the same type (and the 
IGC is working)…

I’d feel more comfortable patching the IGC, but am still trying to fully 
understand the root cause…

/usr/include/bits>diff stat.h stat.h_HOLD
106c106,108
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
164c166,168
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
08:29 smonsees@yix465383 /usr/include/bits>

Note:

tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/3d/common/iStdLib/File.h:

#elif defined(__GNUC__)
#   include 
#   include  <<<---Line #47
#endif

sys/stat.h:

#include  /* For __mode_t and __dev_t.  */

#include 


bits/stat.h:__syscall_slong_t __unused[3];

bits/types.h:__STD_TYPE __SYSCALL_SLONG_TYPE __syscall_slong_t;

#if defined __x86_64__ && defined __ILP32__
bits/typesizes.h:# define __SYSCALL_SLONG_TYPE  
  __SQUAD_TYPE
#else
bits/typesizes.h:# define __SYSCALL_SLONG_TYPE  
  __SLONGWORD_TYPE

#if __WORDSIZE == 32
bits/types.h:# define __SQUAD_TYPE  
   __quad_t
#elif __WORDSIZE == 64
bits/types.h:# define __SQUAD_TYPE  
   long int

bits/types.h:

#define __SLONGWORD_TYPE   long int


From: Monsees, Steven C (US)
Sent: Wednesday, February 2, 2022 8:55 AM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: IGC build issue with devtoolset-8 (GNU 8.3.1)


I am building zeus with basic OpenCL support for centos 7.x, and using GNU 
8.3.1 compiler and see the following Error when IGC is built, I see the same 
error when building with GNU 5.3.1…

Is this a known issue, is a patch available ?
Any ideas why I might be seeing this ?

cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o.d -o 
IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o -c 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp
| In file included from /usr/include/sys/stat.h:106,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp:26:
| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ 
token
|  __syscall_slong_t __unused[3];
|^
| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ 
token
|  __syscall_slong_t __unused[3];
|

I am using bitbake –k, and everything else builds correctly, and no other 
components references this…

If I modify the header like so:

/usr/include/bits>diff stat.h stat.h_HOLD
106c106,108
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
164c166,168
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
08:29 smonsees@yix465383 /usr/include/bits>

IGC builds clean, and test show it appears to working correctly…

I really s

Re: [yocto] IGC build issue with devtoolset-8 (GNU 8.3.1)

[Monsees, Steven C (US) via lists.yoctoproject.org]

Anybody ?

It appears to be a CPP issue in the IGC code... but not sure why.
The "__syscall_slong_t" definition appears to be getting resolved out correctly 
when I replace the array with individual variables of the same type (and the 
IGC is working)...

I'd feel more comfortable patching the IGC, but am still trying to fully 
understand the root cause...

/usr/include/bits>diff stat.h stat.h_HOLD
106c106,108
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
164c166,168
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
08:29 smonsees@yix465383 /usr/include/bits>

Note:

tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/3d/common/iStdLib/File.h:

#elif defined(__GNUC__)
#   include 
#   include  <<<---Line #47
#endif

sys/stat.h:

#include  /* For __mode_t and __dev_t.  */

#include 


bits/stat.h:__syscall_slong_t __unused[3];

bits/types.h:__STD_TYPE __SYSCALL_SLONG_TYPE __syscall_slong_t;

#if defined __x86_64__ && defined __ILP32__
bits/typesizes.h:# define __SYSCALL_SLONG_TYPE  
  __SQUAD_TYPE
#else
bits/typesizes.h:# define __SYSCALL_SLONG_TYPE  
  __SLONGWORD_TYPE

#if __WORDSIZE == 32
bits/types.h:# define __SQUAD_TYPE  
   __quad_t
#elif __WORDSIZE == 64
bits/types.h:# define __SQUAD_TYPE  
   long int

bits/types.h:

#define __SLONGWORD_TYPE   long int


From: Monsees, Steven C (US)
Sent: Wednesday, February 2, 2022 8:55 AM
To: yocto@lists.yoctoproject.org
Subject: IGC build issue with devtoolset-8 (GNU 8.3.1)


I am building zeus with basic OpenCL support for centos 7.x, and using GNU 
8.3.1 compiler and see the following Error when IGC is built, I see the same 
error when building with GNU 5.3.1...

Is this a known issue, is a patch available ?
Any ideas why I might be seeing this ?

cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o.d -o 
IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o -c 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp
| In file included from /usr/include/sys/stat.h:106,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp:26:
| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before '[' 
token
|  __syscall_slong_t __unused[3];
|^
| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before '[' 
token
|  __syscall_slong_t __unused[3];
|

I am using bitbake -k, and everything else builds correctly, and no other 
components references this...

If I modify the header like so:

/usr/include/bits>diff stat.h stat.h_HOLD
106c106,108
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
164c166,168
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
08:29 smonsees@yix465383 /usr/include/bits>

IGC builds clean, and test show it appears to working correctly...

I really shouldn't be modifying the header, and would like to know what the 
real issue issue is...

Thanks,
Steve

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

[yocto] IGC build issue with devtoolset-8 (GNU 8.3.1)

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am building zeus with basic OpenCL support for centos 7.x, and using GNU 
8.3.1 compiler and see the following Error when IGC is built, I see the same 
error when building with GNU 5.3.1...

Is this a known issue, is a patch available ?
Any ideas why I might be seeing this ?

cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o.d -o 
IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o -c 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp
| In file included from /usr/include/sys/stat.h:106,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,
|  from 
/disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp:26:
| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before '[' 
token
|  __syscall_slong_t __unused[3];
|^
| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before '[' 
token
|  __syscall_slong_t __unused[3];
|

I am using bitbake -k, and everything else builds correctly, and no other 
components references this...

If I modify the header like so:

/usr/include/bits>diff stat.h stat.h_HOLD
106c106,108
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
164c166,168
< __syscall_slong_t __unused[3];
---
> __syscall_slong_t __unused1;
> __syscall_slong_t __unused2;
> __syscall_slong_t __unused3;
08:29 smonsees@yix465383 /usr/include/bits>

IGC builds clean, and test show it appears to working correctly...

I really shouldn't be modifying the header, and would like to know what the 
real issue issue is...

Thanks,
Steve

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

Re: [yocto] hosttools

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thank you, this explains/fixes an anomaly I saw while building under Jenkins...

-Original Message-
From: Richard Purdie  
Sent: Monday, January 10, 2022 8:43 AM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] hosttools

External Email Alert

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

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


On Mon, 2022-01-10 at 13:21 +, Monsees, Steven C (US) via 
lists.yoctoproject.org wrote:
>  
> How does yocto determine the locations/paths to the “hosttools” ?
>  
> Is there precedence order established for locating the “hosttools” ?,  
> and how would one update the search list so as to pick the tool from a 
> different/specific location ?
>  

It uses PATH, just like the shell would. You'd adjust PATH to influence it.

Once it is constructed you have to remove the path to cause it to be 
regenerated.

Cheers,

Richard


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

[yocto] hosttools

[Monsees, Steven C (US) via lists.yoctoproject.org]

How does yocto determine the locations/paths to the "hosttools" ?

Is there precedence order established for locating the "hosttools" ?,  and
how would one update the search list so as to pick the tool from a 
different/specific location ?


Thanks,
Steve

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

Re: [yocto] BBLAYERS

[Monsees, Steven C (US) via lists.yoctoproject.org]

Is it possible to use BBMASK to remove from builds ?

From: Monsees, Steven C (US)
Sent: Tuesday, January 4, 2022 2:32 PM
To: 'yocto@lists.yoctoproject.org' 
Subject: RE: BBLAYERS


Any suggestions... ?

From: Monsees, Steven C (US)
Sent: Tuesday, January 4, 2022 7:22 AM
To: yocto@lists.yoctoproject.org
Subject: BBLAYERS


Under my Yocto build, I have basically 2 build directories (one for Arm and one 
for Intel platforms)... each build directory has its own bblayer.conf.

Under each of these directories I build multiple images for each platform...

If say, on the Intel side, I can build for 3 MACHINES creating 3 unique kernel 
images A, B, and C (they all share a common bblayer.conf) and I then want to 
modify one kernel to include meta-virtualization...

How would I manage the bblayer.conf to add this layer to only B's build so as 
not to impact the building of "A"  or "C" ?

If I just add it to the common bblayer.conf, "A" and "C" are impacted by the 
addition and show:

WARNING: You have included the meta-virtualization layer, but 'virtualization' 
has not been enabled in your DISTRO_FEATURES. Some bbappend files may not take 
effect. See the meta-virtualization README for details on enabling 
virtualization support.

Thanks,
Steve

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

Re: [yocto] BBLAYERS

[Monsees, Steven C (US) via lists.yoctoproject.org]

Any suggestions... ?

From: Monsees, Steven C (US)
Sent: Tuesday, January 4, 2022 7:22 AM
To: yocto@lists.yoctoproject.org
Subject: BBLAYERS


Under my Yocto build, I have basically 2 build directories (one for Arm and one 
for Intel platforms)... each build directory has its own bblayer.conf.

Under each of these directories I build multiple images for each platform...

If say, on the Intel side, I can build for 3 MACHINES creating 3 unique kernel 
images A, B, and C (they all share a common bblayer.conf) and I then want to 
modify one kernel to include meta-virtualization...

How would I manage the bblayer.conf to add this layer to only B's build so as 
not to impact the building of "A"  or "C" ?

If I just add it to the common bblayer.conf, "A" and "C" are impacted by the 
addition and show:

WARNING: You have included the meta-virtualization layer, but 'virtualization' 
has not been enabled in your DISTRO_FEATURES. Some bbappend files may not take 
effect. See the meta-virtualization README for details on enabling 
virtualization support.

Thanks,
Steve

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

[yocto] BBLAYERS

[Monsees, Steven C (US) via lists.yoctoproject.org]

Under my Yocto build, I have basically 2 build directories (one for Arm and one 
for Intel platforms)... each build directory has its own bblayer.conf.

Under each of these directories I build multiple images for each platform...

If say, on the Intel side, I can build for 3 MACHINES creating 3 unique kernel 
images A, B, and C (they all share a common bblayer.conf) and I then want to 
modify one kernel to include meta-virtualization...

How would I manage the bblayer.conf to add this layer to only B's build so as 
not to impact the building of "A"  or "C" ?

If I just add it to the common bblayer.conf, "A" and "C" are impacted by the 
addition and show:

WARNING: You have included the meta-virtualization layer, but 'virtualization' 
has not been enabled in your DISTRO_FEATURES. Some bbappend files may not take 
effect. See the meta-virtualization README for details on enabling 
virtualization support.

Thanks,
Steve

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

Re: [yocto] meta-virtualization/docker/containerd issue seen

[Monsees, Steven C (US) via lists.yoctoproject.org]

Nevermind…

I forgot if you have added the docker-ce recipe to the build then it does spawn 
the docker daemon automatically, even if it’s sysvinit…

Thanks anyway, and Happy Holidays…

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, December 23, 2021 1:27 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] meta-virtualization/docker/containerd issue seen

External Email Alert

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



I am trying to build in basic docker functionality for container support…

I am zeus based, and am building docker and docker-ce-contrib.

When I manually start the dockerd in the background I am seeing a timeout when 
attempting to use containerd.

Any ideas as ti why I am getting this error or how I might resolve it ?
(see bottom)

Thanks,
Steve

Initialization complete. Sending init complete message
Running indefinitely

root@sbca-default which docker
/usr/bin/docker
root@sbca-default docker --version
Docker version 19.03.2-ce, build 6a30dfc
root@sbca-default docker info
Client:
Debug Mode: false

Server:
Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
Images: 0
Server Version: 19.03.2-ce
Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk 
syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: fd103cb716352c7e19768e4fed057f71d68902a0.m
runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f-dirty
init version: fec3683-dirty (expected: fec3683b971d9)
Kernel Version: 4.19.135-intel-pk-standard
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.51GiB
Name: sbca-default
ID: YFQW:EPJT:TSJU:C64F:NU57:RAJL:X5IC:J5IT:MRTP:SIGS:RI25:KUFQ
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
  localhost:5000
  127.0.0.0/8
Registry Mirrors:
  http://localhost:5000/
Live Restore Enabled: false

root@sbca-default /usr/share/docker/check-config.sh
info: reading kernel config from /proc/config.gz ...

Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: enabled (as module)
- CONFIG_NF_NAT_IPV4: enabled (as module)
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: enabled
- CONFIG_POSIX_MQUEUE: enabled

Optional Features:
- CONFIG_USER_NS: enabled
- CONFIG_SECCOMP: enabled
- CONFIG_CGROUP_PIDS: enabled
- CONFIG_MEMCG_SWAP: enabled
- CONFIG_MEMCG_SWAP_ENABLED: enabled
(cgroup swap accounting is currently enabled)
- CONFIG_LEGACY_VSYSCALL_EMULATE: enabled
- CONFIG_BLK_CGROUP: enabled
- CONFIG_BLK_DEV_THROTTLING: enabled
- CONFIG_IOSCHED_CFQ: enabled
- CONFIG_CFQ_GROUP_IOSCHED: enabled
- CONFIG_CGROUP_PERF: enabled
- CONFIG_CGROUP_HUGETLB: enabled
- CONFIG_NET_CLS_CGROUP: enabled
- CONFIG_CGROUP_NET_PRIO: enabled
- CONFIG_CFS_BANDWIDTH: enabled
- CONFIG_FAIR_GROUP_SCHED: enabled
- CONFIG_RT_GROUP_SCHED: enabled
- CONFIG_IP_NF_TARGET_REDIRECT: enabled (as module)
- CONFIG_IP_VS: enabled (as module)
- CONFIG_IP_VS_NFCT: enabled
- CONFIG_IP_VS_PROTO_TCP: enabled
- CONFIG_IP_VS_PROTO_UDP: enabled
- CONFIG_IP_VS_RR: enabled (as module)
- CONFIG_EXT4_FS: enabled
- CONFIG_EXT4_FS_POSIX_ACL: enabled
- CONFIG_EXT4_FS_SECURITY: enabled
- Network Drivers:
  - "overlay":
- CONFIG_VXLAN: enabled
  Optional (for encrypted networks):
  - CONFIG_CRYPTO: enabled
  - CONFIG_CRYPTO_AEAD: enabled
  - CONFIG_CRYPTO_GCM: enabled (as module)
  - CONFIG_CRYPTO_SEQIV: enabled
  - CONFIG_CRYPTO_GHASH: enabled (as module)
  - CONFIG_XFRM: enabled
  - CONFIG_XFRM_USER: enabled (as module)
  - CONFIG

[yocto] meta-virtualization/docker/containerd issue seen

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am trying to build in basic docker functionality for container support...

I am zeus based, and am building docker and docker-ce-contrib.

When I manually start the dockerd in the background I am seeing a timeout when 
attempting to use containerd.

Any ideas as ti why I am getting this error or how I might resolve it ?
(see bottom)

Thanks,
Steve

Initialization complete. Sending init complete message
Running indefinitely

root@sbca-default which docker
/usr/bin/docker
root@sbca-default docker --version
Docker version 19.03.2-ce, build 6a30dfc
root@sbca-default docker info
Client:
Debug Mode: false

Server:
Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
Images: 0
Server Version: 19.03.2-ce
Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk 
syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: fd103cb716352c7e19768e4fed057f71d68902a0.m
runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f-dirty
init version: fec3683-dirty (expected: fec3683b971d9)
Kernel Version: 4.19.135-intel-pk-standard
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.51GiB
Name: sbca-default
ID: YFQW:EPJT:TSJU:C64F:NU57:RAJL:X5IC:J5IT:MRTP:SIGS:RI25:KUFQ
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
  localhost:5000
  127.0.0.0/8
Registry Mirrors:
  http://localhost:5000/
Live Restore Enabled: false

root@sbca-default /usr/share/docker/check-config.sh
info: reading kernel config from /proc/config.gz ...

Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: enabled (as module)
- CONFIG_NF_NAT_IPV4: enabled (as module)
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: enabled
- CONFIG_POSIX_MQUEUE: enabled

Optional Features:
- CONFIG_USER_NS: enabled
- CONFIG_SECCOMP: enabled
- CONFIG_CGROUP_PIDS: enabled
- CONFIG_MEMCG_SWAP: enabled
- CONFIG_MEMCG_SWAP_ENABLED: enabled
(cgroup swap accounting is currently enabled)
- CONFIG_LEGACY_VSYSCALL_EMULATE: enabled
- CONFIG_BLK_CGROUP: enabled
- CONFIG_BLK_DEV_THROTTLING: enabled
- CONFIG_IOSCHED_CFQ: enabled
- CONFIG_CFQ_GROUP_IOSCHED: enabled
- CONFIG_CGROUP_PERF: enabled
- CONFIG_CGROUP_HUGETLB: enabled
- CONFIG_NET_CLS_CGROUP: enabled
- CONFIG_CGROUP_NET_PRIO: enabled
- CONFIG_CFS_BANDWIDTH: enabled
- CONFIG_FAIR_GROUP_SCHED: enabled
- CONFIG_RT_GROUP_SCHED: enabled
- CONFIG_IP_NF_TARGET_REDIRECT: enabled (as module)
- CONFIG_IP_VS: enabled (as module)
- CONFIG_IP_VS_NFCT: enabled
- CONFIG_IP_VS_PROTO_TCP: enabled
- CONFIG_IP_VS_PROTO_UDP: enabled
- CONFIG_IP_VS_RR: enabled (as module)
- CONFIG_EXT4_FS: enabled
- CONFIG_EXT4_FS_POSIX_ACL: enabled
- CONFIG_EXT4_FS_SECURITY: enabled
- Network Drivers:
  - "overlay":
- CONFIG_VXLAN: enabled
  Optional (for encrypted networks):
  - CONFIG_CRYPTO: enabled
  - CONFIG_CRYPTO_AEAD: enabled
  - CONFIG_CRYPTO_GCM: enabled (as module)
  - CONFIG_CRYPTO_SEQIV: enabled
  - CONFIG_CRYPTO_GHASH: enabled (as module)
  - CONFIG_XFRM: enabled
  - CONFIG_XFRM_USER: enabled (as module)
  - CONFIG_XFRM_ALGO: enabled
  - CONFIG_INET_ESP: enabled (as module)
  - CONFIG_INET_XFRM_MODE_TRANSPORT: enabled
  - "ipvlan":
- CONFIG_IPVLAN: enabled
  - "macvlan":
- CONFIG_MACVLAN: enabled
- CONFIG_DUMMY: enabled
  - "ftp,tftp client in container":
- CONFIG_NF_NAT_FTP: enabled (as module)
- CONFIG_NF_CONNTRACK_FTP: enabled (as module)
- CONFIG_NF_NAT_TFTP: enabled (as module)
- CONFIG_NF_CONNTRACK_TFTP: enabled (as module)
- Storage Drivers:
  - "aufs":
- CONFIG_AUFS_FS: missing
  - "btrfs":
- CONFIG_BTRFS_FS: enabled
- CONFIG_BTRFS_FS_POSIX_ACL: enabled
  - "devicemapper":
- CONFIG_BLK_DEV_DM: enabled
- CONFIG_DM_THIN_PROVISIONING: enabled
  - "overlay":
- CONFIG_OVERLAY_FS: enabled
  - "zfs":
- /dev/zfs: missing
- zfs command: missing
- zpool command: missing

Limits:
- 

Re: [yocto] Yocto BUILD ENV

[Monsees, Steven C (US) via lists.yoctoproject.org]

: expected unqualified-id before ‘[’ 
token
|  __syscall_slong_t __unused[3];
|^
| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ 
token
|  __syscall_slong_t __unused[3];
|^


From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, December 14, 2021 2:23 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] Yocto BUILD ENV

External Email Alert

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



I am using a pre-installed tools on my linux development box for centos7, that 
being devtoolset-8…

Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, 
kernel, and the standard SDK without issues…, but there seems to be a problem 
when I go to build the extended SDK.

It appears to end up referencing the wrong/default tool set.

Is the something I need to set in my sdk-extra.conf (or one of the vcarious 
other configuration files)  to make the extended SDK build aware of the 
environment dependency ?


/opt/rh/devtoolset-8/enable script does the following:

# General environment variables
export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}}
export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH}
export 
INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}}
export PCP_DIR=/opt/rh/devtoolset-8/root
# Some perl Ext::MakeMaker versions install things under /usr/lib/perl5
# even though the system otherwise would go to /usr/lib64/perl5.
export 
PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}}
# bz847911 workaround:
# we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time
# or else /etc/ld.so.conf.d files?
rpmlibdir=$(rpm --eval "%{_libdir}")
# bz1017604: On 64-bit hosts, we should include also the 32-bit library path.
if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then
  rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}"
fi
export 
LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export 
LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
# duplicate python site.py logic for sitepackages
pythonvers=2.7
export 
PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}}
export 
PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}


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

[yocto] Yocto BUILD ENV

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am using a pre-installed tools on my linux development box for centos7, that 
being devtoolset-8...

Running "source /opt/rh/devtoolset-8/enable" allows me to build my bootapp, 
kernel, and the standard SDK without issues..., but there seems to be a problem 
when I go to build the extended SDK.

It appears to end up referencing the wrong/default tool set.

Is the something I need to set in my sdk-extra.conf (or one of the vcarious 
other configuration files)  to make the extended SDK build aware of the 
environment dependency ?


/opt/rh/devtoolset-8/enable script does the following:

# General environment variables
export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}}
export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH}
export 
INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}}
export PCP_DIR=/opt/rh/devtoolset-8/root
# Some perl Ext::MakeMaker versions install things under /usr/lib/perl5
# even though the system otherwise would go to /usr/lib64/perl5.
export 
PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}}
# bz847911 workaround:
# we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time
# or else /etc/ld.so.conf.d files?
rpmlibdir=$(rpm --eval "%{_libdir}")
# bz1017604: On 64-bit hosts, we should include also the 32-bit library path.
if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then
  rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}"
fi
export 
LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export 
LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
# duplicate python site.py logic for sitepackages
pythonvers=2.7
export 
PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}}
export 
PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}


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

Re: [yocto] standard SDK build with clang compiler built into kernel image

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks again, will take a look and give it a try...

-Original Message-
From: Khem Raj  
Sent: Thursday, December 9, 2021 2:55 PM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] standard SDK build with clang compiler built into kernel 
image

External Email Alert

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

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


This is a known issue look at

https://github.com/kraj/meta-clang/issues/119

You can workaround it by

https://github.com/kraj/meta-clang/issues/119#issuecomment-518317888

On Thu, Dec 9, 2021 at 11:22 AM Monsees, Steven C (US) via 
lists.yoctoproject.org  
wrote:
>
>
>
> I am building clang compiler support into my kernel, to support igc 
> (intel graphics compiler)…
>
>
>
> When I build the standard SDK it list a series of specific clang/llvm issues 
> but successfully completes the SDK setup/install.
>
> The SDK looks to have everything in place, and basic functionality is 
> working…
>
>
>
> I do not see these messages when I remove the clang component.
>
>
>
> Can someone explain what is happening here ?, is it a known issue  ?, is 
> there patch available ?
>
>
>
> I am building a “zeus” 3.0.4 based kernel, for centos…
>
>
>
> -bash-4.2$ cd sdk
>
> -bash-4.2$ ls
>
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.host.manifest
>
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.sh
>
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.target.manife
> st
>
> limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.testdata.json
>
> -bash-4.2$  sudo 
> ./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.sh
>
> [sudo] password for smonsees:
>
> LIMWS (BAE LIMWS base distro) SDK installer version 3.0.4
>
> =
>
> Enter target directory for SDK (default: /opt/limws/3.0.4): 
> /disk0/scratch/smonsees/yocto/sdk_3.0.4
>
> You are about to install the SDK to 
> "/disk0/scratch/smonsees/yocto/sdk_3.0.4". Proceed [Y/n]? Y
>
> Extracting 
> SDK...
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..
> ..done
>
> Setting it up...ERROR: could not relocate 
> /disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-tidy,
>  interp size = 72 and 95 is needed.
>
> ERROR: could not relocate 
> /disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-cxxdump,
>  interp size = 72 and 95 is needed.
>
> ERROR: could not relocate 
> /disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-ar,
>  interp size = 72 and 95 is needed.
>
> ERROR: could not relocate 
> /disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-symbolizer,
>  interp size = 72 and 95 is needed.
>
> ERROR: could not relocate 
> /disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-9,
>  interp size = 72 and 95 is needed.
>
> ERROR: could not relocate 
> /disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-as,
>  interp size = 72 and 95 is needed.
>
> ERROR: could not relocate 
> /disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-extdef-mapping,
>  interp

[yocto] standard SDK build with clang compiler built into kernel image

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am building clang compiler support into my kernel, to support igc (intel 
graphics compiler)...

When I build the standard SDK it list a series of specific clang/llvm issues 
but successfully completes the SDK setup/install.
The SDK looks to have everything in place, and basic functionality is working...

I do not see these messages when I remove the clang component.

Can someone explain what is happening here ?, is it a known issue  ?, is there 
patch available ?

I am building a "zeus" 3.0.4 based kernel, for centos...

-bash-4.2$ cd sdk
-bash-4.2$ ls
limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.host.manifest
limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.sh
limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.target.manifest
limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.testdata.json
-bash-4.2$  sudo ./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-3.0.4.sh
[sudo] password for smonsees:
LIMWS (BAE LIMWS base distro) SDK installer version 3.0.4
=
Enter target directory for SDK (default: /opt/limws/3.0.4): 
/disk0/scratch/smonsees/yocto/sdk_3.0.4
You are about to install the SDK to "/disk0/scratch/smonsees/yocto/sdk_3.0.4". 
Proceed [Y/n]? Y
Extracting 
SDK...done
Setting it up...ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-tidy,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-cxxdump,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-ar,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-symbolizer,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-9,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-as,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-extdef-mapping,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-reorder-fields,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-mca,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-apply-replacements,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-dwarfdump,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/llvm-elfabi,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/lldb-instr,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/c-index-test,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/clang-doc,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 
/disk0/scratch/smonsees/yocto/sdk_3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/lldb-tblgen,
 interp size = 72 and 95 is needed.
ERROR: could not relocate 

[yocto] NFS under yocto

[Monsees, Steven C (US) via lists.yoctoproject.org]

Current yocto build is based on zeus...
We have one board running Yocto Embedded linux that is sharing a drive 
partition via NFS.
Another board is mounting the NFS share and has a few processes that can write 
data to the drive.
We are seeing conditions were concurrent writes (two client processes) appear 
to result in "Stale File Handles".
The drive partition is using the NTFS file system.

We are wondering if there are any issues in the NFS Server or Client that could 
be causing these "Stale File Handles".
We have tried to change some of the options used to mount the NFS share.
Are there any options in how the location is shared that we should try?

Anyone hear about or experienced similar issues ?

Thanks,
Steve

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

[yocto] meta-intel / zeus

[Monsees, Steven C (US) via lists.yoctoproject.org]

Recently I built in base intel NEO driver components under meta-intel...
It appears I require a little more than just NEO.

Does yocto support the khronos icd loader ?,
Is there something I can build/enable tp provide this ?

Currently running under zeus, but if a newer version of Yocto supports it that 
would be good to know.

Thanks,
Steve

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

[yocto] how to handle third party licenses

[Monsees, Steven C (US) via lists.yoctoproject.org]

Looking for the proper Yocto way to handle third party software ported to Yocto 
and built into kernel...

I'm not having issues when I recognize the license as a generic license. But 
the license provided to us by the vendor is not part of the generic licenses 
list that you (Yocto) recognize.

I was wondering if you could explain how to add a custom license to a recipe in 
yocto.

The vendor has provided us with a generic license.txt file and I was able to 
add that to the our recipe. I do get a warning though which says:

WARNING: aiox-defaultfs-1.0-r0 do_rootfs: The license listed 
DataDeviceCorporation was not in the licenses collected for recipe acexpci

Though the warning occurs, I can see the license.txt being saved inside the 
rootfs on our board and is saved under tmp/deploy/licenses/acexpci. I've been 
trying to get rid of this warning when the image builds, but I can't seem to 
find anything in the manual or online. One solution says : Add LICENSE_PATH += 
"${LAYERDIR}/custom-licenses" under conf/layer.conf, which does not resolve 
this warning.

I am currently building with Yocto zeus...

Thanks,
Steve


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

Re: [yocto] preempt-rt

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks…


From: yocto@lists.yoctoproject.org  On Behalf Of 
codusnocturnus via lists.yoctoproject.org
Sent: Wednesday, November 3, 2021 9:25 AM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] preempt-rt

External Email Alert

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




‐‐‐ Original Message ‐‐‐
On Wednesday, November 3rd, 2021 at 5:43 AM, Monsees, Steven C (US) via 
lists.yoctoproject.org 
mailto:steven.monsees=baesystems@lists.yoctoproject.org>>
 wrote:




I have a platform based off a aarm64 Xilinx based kernel, which is not a 
compliant mainline kernel… so, I will need to go the preemp-rt patch route.



Can you supply an example Yocto recipe that applies the patch, doesn’t even 
have to be arm based… just looking for baseline I might use to carve out 
support for my platform.

There are a few details to sort out (like finding a patch compatible with the 
kernel recipe you want to use, or a compromise of the two), but basically a 
kernel .bbappend with the following will suffice to just patch the kernel.
FILES_EXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append = " 
https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.12/patch-5.12-rc3-rt3.patch.gz;

After that, you need a configuration fragment to enable PREEMPT-RT in the build.
CONFIG_PREEMPT_RT=y




Thanks,

Steve
Sent with ProtonMail<https://protonmail.com/> Secure Email.




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

Re: [yocto] preempt-rt

[Monsees, Steven C (US) via lists.yoctoproject.org]

Cannot…

Generic preempt-rt patch bbappend should be enough…


From: Leon Woestenberg 
Sent: Wednesday, November 3, 2021 8:59 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] preempt-rt

External Email Alert

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


Hello Steve,

On Wed, 3 Nov 2021 at 13:44, Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:

I have a platform based off a aarm64 Xilinx based kernel, which is not a 
compliant mainline kernel… so, I will need to go the preemp-rt patch route.

Depends, no mainline kernel? Vendor kernel?

Can you share the machine name? Might be supported already in a layer with -rt.

Regards,

Leon
--
--
Leon Woestenberg
l...@sidebranch.com<mailto:l...@sidebranch.com>
T: +31 40 711 42 76
M: +31 6 472 30 372
[Image removed by sender.]
Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com


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

[yocto] preempt-rt

[Monsees, Steven C (US) via lists.yoctoproject.org]

I have a platform based off a aarm64 Xilinx based kernel, which is not a 
compliant mainline kernel... so, I will need to go the preemp-rt patch route.

Can you supply an example Yocto recipe that applies the patch, doesn't even 
have to be arm based... just looking for baseline I might use to carve out 
support for my platform.

Thanks,
Steve

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

[yocto] yocto preempt-rt

[Monsees, Steven C (US) via lists.yoctoproject.org]

Is it true that no patch work is required if out under
.../poky/meta/recipes-kernel, there exists  a yocto-linux-rt_##.##.bb recipe 
that matches your kernel release?, and that it will build the full preemptive 
RT Kernel ?

Thanks,
Steve


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

Re: [yocto] yocto meta-intel preempt-rt

[Monsees, Steven C (US) via lists.yoctoproject.org]

I will check...

Would you have an example of a recipe that shows how to apply the rt path ?

Thanks,
Steve

-Original Message-
From: Leon Woestenberg  
Sent: Tuesday, November 2, 2021 8:25 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] yocto meta-intel preempt-rt

External Email Alert

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

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


Hello Steve,

I have been running the PREEMPT_RT for Intel platforms for a few releases, I 
remember it fetched sources from a GIT branch for -rt (PREEMPT_RT). So it does 
not need to apply separate patches in that case.

Could you check if this is the case for you as well?

Regards,

Leon.

p.s. Slightly off-topic, I moved away from PREEMPT_RT in favor of task 
isolation mode, where we use one CPU core in isolated single task mode, for 
*much* lower latencies than PREEMPT_RT can provide.


--
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Tue, Nov 2, 2021 at 12:30 PM Monsees, Steven C (US) via 
lists.yoctoproject.org  
wrote:
>
>
>
> I have an Intel based platform, and was looking to implement preempt-rt on it 
> to test.
>
>
>
> For Intel, the meta-intel component recipe appears to supports 
> “linux-intel-rt”, and I can build my intel based platform with this  
> and it boots…  My platform kernel is currently 4.19 based under the 
> meta-inteI component I do not see the rt patch/patches being applied…
>
>
>
> Is meta-intel component recipe building the full preempt-rt support ?, or do 
> I still need to apply the patch ?
>
>
>
> Thanks,
>
> Steve
>
>
>
>
> 
>

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

[yocto] yocto meta-intel preempt-rt

[Monsees, Steven C (US) via lists.yoctoproject.org]

I have an Intel based platform, and was looking to implement preempt-rt on it 
to test.

For Intel, the meta-intel component recipe appears to supports 
"linux-intel-rt", and I can build my intel based platform with this  and it 
boots...  My platform kernel is currently 4.19 based under the meta-inteI 
component I do not see the rt patch/patches being applied...

Is meta-intel component recipe building the full preempt-rt support ?, or do I 
still need to apply the patch ?

Thanks,
Steve


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

Re: [yocto] bbappend usage

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am looking to selectively remove portions of 1or 2 components I will not be 
using from my running image

-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Leon Woestenberg
Sent: Monday, October 25, 2021 9:12 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] bbappend usage

External Email Alert

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

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


Hello Steve,

Is the approach where you remove the recipes from the image an option?
Is there a reason why you want to build the recipes that you do not want to 
appear in your image?

Regards,

Leon.


--
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Mon, Oct 25, 2021 at 2:55 PM Monsees, Steven C (US) via 
lists.yoctoproject.org  
wrote:
>
>
>
> Hello:
>
>
>
> If I am building an image “image-ABC”, and it is composed of a number 
> recipes, and for some of these recipes I may NOT want to install their 
> final components within my image…
>
>
>
> Which is the best place to modify the build with bbappend ?
>
>
>
> Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or 
> would I modify the image recipe (do_install_append-image_ABC) I am leaning 
> this way to avoid cases where the component recipes might have bbappends in 
> place already ?
>
>
>
> Looking for the proper Yocto way…
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
> 
>

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

Re: [yocto] bbappend usage

[Monsees, Steven C (US) via lists.yoctoproject.org]

No, you got it wromg... I have a buildable image which has all the components 
necessary, I want to remove some overhead installed by some components that I 
will not be within my running application... 

-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Robert P. J. Day
Sent: Monday, October 25, 2021 9:10 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] bbappend usage

External Email Alert

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

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


On Mon, 25 Oct 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

> If I am building an image “image-ABC”, and it is composed of a number 
> recipes, and for some of these recipes I may NOT want to install their 
> final components within my image…
>
> Which is the best place to modify the build with bbappend ?
>
> Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, 
> or would I modify the image recipe (do_install_append-image_ABC) I am 
> leaning this way to avoid cases where the component recipes might have 
> bbappends in place already ?

  i would think start with defining a minimal image, then define other images 
based on that one which add more recipes. this has nothing to do with 
redefining the recipes, it just means defining more than one image.

rday

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

[yocto] bbappend usage

[Monsees, Steven C (US) via lists.yoctoproject.org]

Hello:

If I am building an image "image-ABC", and it is composed of a number recipes, 
and for some of these recipes I may NOT want to install their final components 
within my image...

Which is the best place to modify the build with bbappend ?

Would I modify a recipe's do_install (do_install_append-recipe_xyz) ?, or would 
I modify the image recipe (do_install_append-image_ABC) I am leaning this way 
to avoid cases where the component recipes might have bbappends in place 
already ?

Looking for the proper Yocto way...

Thanks,
Steve



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

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am able to build clean...

One question, "clang" is a dependency for the build of the NEO driver, once 
built, do I still require clang as part of my image ?, or can I remove the 
clang component in the recipe that creates my final image ?

Clang takes up a lot space, if not needed in the end, I'd like to be able to 
remove and reduce the size of my image.

Thanks again for your help,
Steve

-Original Message-
From: Mittal, Anuj  
Sent: Wednesday, October 13, 2021 9:28 PM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


There are no patches needed other than what is already in oe-core/meta- 
intel/meta-clang. I tried building zeus on Ubuntu 16.04 and didn't see any 
problem.

zeus is no longer maintained or supported so I'd suggest checking a newer 
release or experimenting without using buildtools to see if that is exposing 
this problem. It does look like things are not being compiled properly or 
perhaps opencl-clang-native is linking to incorrect LLVM ... 

Thanks,

Anuj

On Wed, 2021-10-13 at 16:53 +, Monsees, Steven C (US) wrote:
> 
> Anything ?, I have yet to resolve this.
> 
> -Original Message-
> From: Monsees, Steven C (US)
> Sent: Wednesday, October 13, 2021 9:03 AM
> To: 'Mittal, Anuj' ; 
> 'yocto@lists.yoctoproject.org' 
> Subject: RE: [yocto] #zeus meta-intel
> 
> 
> Are there any patches required for these components (igc, opencl- 
> clang, and intel-compute-runtime) ?
> 
> -Original Message-
> From: Monsees, Steven C (US)
> Sent: Wednesday, October 13, 2021 7:13 AM
> To: 'Mittal, Anuj' ; 
> yocto@lists.yoctoproject.org
> Subject: RE: [yocto] #zeus meta-intel
> 
> 
> Anuj:
> 
> I rebuilt the entire image (but did not delete the state_cache)...
> I am building meta-clang (zeus based, I believe it is 9.0.1).
> 
> Steve
> 
> -Original Message-
> From: Mittal, Anuj 
> Sent: Tuesday, October 12, 2021 10:10 PM
> To: Monsees, Steven C (US) ; 
> yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #zeus meta-intel
> 
> External Email Alert
> 
> This email has been sent from an account outside of the BAE Systems 
> network.
> 
> Please treat the email with caution, especially if you are requested 
> to click on a link, decrypt/open an attachment, or enable macros.
> For further information on how to spot phishing, access “Cybersecurity 
> OneSpace Page” and report phishing by clicking the button “Report 
> Phishing” on the Outlook toolbar.
> 
> 
> Did you build everything with this compiler from start? Is opencl- 
> clang building with the right LLVM lib from meta-clang?
> 
> Thanks,
> 
> Anuj
> 
> On Tue, 2021-10-12 at 17:15 +, Monsees, Steven C (US) wrote:
> > 
> > Anuj:
> > 
> > I picked up the tarball for for the baseline dunfell tools platform 
> > to update host tools...
> > 
> > I am seeing it compile cleaner but for one issue causng ld to fail:
> > 
> > /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> > default/tmp/work/x86_64-linux/intel-graphics-compiler-
> > native/1.0.11-
> > r0/recipe-sysroot-
> > native/usr/include/llvm/Support/CommandLine.h:1331:
> > undefined reference to `vtable for
> > llvm::cl::opt > std::char_traits,
> > std::allocator >, false,
> > llvm::cl::parser > std::char_traits, std::allocator > > >'
> > 
> > Isn't LLVM brought in along with clang under meta-clang ?
> > 
> > Is there a missing build dependency ?
> > 
> > Thanks,
> > Steve
> > 
> > Build excerpt showing multiple " undefined reference to `vtable "
> > errors...
> > 
> > /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> > pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> > `llvm::cl::opt > std::char_traits, std::allocator >, false, 
> > llvm::cl::parser > std::char_traits, std::allocator > > >::~opt()':
> > /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> > default/tmp/work/x86_64-linux/intel-graphics-compiler-
> > native/1.0.11-
> > r0/recipe-sysroot-
> > native/usr/include/llvm/Support/CommandLine.h:1331:
> > undefined reference to `vtable for
> > llvm::cl::opt > std::char_traits,
> > std::allocator >, false,
> > llvm::cl::parser > std::char_traits, std::allocator > > >'
> > /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> > pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> > `llvm::cl::OptionValue > std::char_traits, std::allocator > >::OptionValue()':
> > /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> > default/tmp/work/x86_64-linux/intel-graphics-compiler-
> > native/1.0.11-
> > r0/recipe-sysroot-
> > 

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thank you.

I will most likely look into creating a  dunfell based build this weekend...
My current system is zeus based, centos, still using sysvinit on startup...

Did run using clang 9.0 ?

I appreciate your time and trouble,
Steve

-Original Message-
From: Mittal, Anuj  
Sent: Wednesday, October 13, 2021 9:28 PM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


There are no patches needed other than what is already in oe-core/meta- 
intel/meta-clang. I tried building zeus on Ubuntu 16.04 and didn't see any 
problem.

zeus is no longer maintained or supported so I'd suggest checking a newer 
release or experimenting without using buildtools to see if that is exposing 
this problem. It does look like things are not being compiled properly or 
perhaps opencl-clang-native is linking to incorrect LLVM ... 

Thanks,

Anuj

On Wed, 2021-10-13 at 16:53 +, Monsees, Steven C (US) wrote:
> 
> Anything ?, I have yet to resolve this.
> 
> -Original Message-
> From: Monsees, Steven C (US)
> Sent: Wednesday, October 13, 2021 9:03 AM
> To: 'Mittal, Anuj' ; 
> 'yocto@lists.yoctoproject.org' 
> Subject: RE: [yocto] #zeus meta-intel
> 
> 
> Are there any patches required for these components (igc, opencl- 
> clang, and intel-compute-runtime) ?
> 
> -Original Message-
> From: Monsees, Steven C (US)
> Sent: Wednesday, October 13, 2021 7:13 AM
> To: 'Mittal, Anuj' ; 
> yocto@lists.yoctoproject.org
> Subject: RE: [yocto] #zeus meta-intel
> 
> 
> Anuj:
> 
> I rebuilt the entire image (but did not delete the state_cache)...
> I am building meta-clang (zeus based, I believe it is 9.0.1).
> 
> Steve
> 
> -Original Message-
> From: Mittal, Anuj 
> Sent: Tuesday, October 12, 2021 10:10 PM
> To: Monsees, Steven C (US) ; 
> yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #zeus meta-intel
> 
> External Email Alert
> 
> This email has been sent from an account outside of the BAE Systems 
> network.
> 
> Please treat the email with caution, especially if you are requested 
> to click on a link, decrypt/open an attachment, or enable macros.
> For further information on how to spot phishing, access “Cybersecurity 
> OneSpace Page” and report phishing by clicking the button “Report 
> Phishing” on the Outlook toolbar.
> 
> 
> Did you build everything with this compiler from start? Is opencl- 
> clang building with the right LLVM lib from meta-clang?
> 
> Thanks,
> 
> Anuj
> 
> On Tue, 2021-10-12 at 17:15 +, Monsees, Steven C (US) wrote:
> > 
> > Anuj:
> > 
> > I picked up the tarball for for the baseline dunfell tools platform 
> > to update host tools...
> > 
> > I am seeing it compile cleaner but for one issue causng ld to fail:
> > 
> > /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> > default/tmp/work/x86_64-linux/intel-graphics-compiler-
> > native/1.0.11-
> > r0/recipe-sysroot-
> > native/usr/include/llvm/Support/CommandLine.h:1331:
> > undefined reference to `vtable for
> > llvm::cl::opt > std::char_traits,
> > std::allocator >, false,
> > llvm::cl::parser > std::char_traits, std::allocator > > >'
> > 
> > Isn't LLVM brought in along with clang under meta-clang ?
> > 
> > Is there a missing build dependency ?
> > 
> > Thanks,
> > Steve
> > 
> > Build excerpt showing multiple " undefined reference to `vtable "
> > errors...
> > 
> > /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> > pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> > `llvm::cl::opt > std::char_traits, std::allocator >, false, 
> > llvm::cl::parser > std::char_traits, std::allocator > > >::~opt()':
> > /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> > default/tmp/work/x86_64-linux/intel-graphics-compiler-
> > native/1.0.11-
> > r0/recipe-sysroot-
> > native/usr/include/llvm/Support/CommandLine.h:1331:
> > undefined reference to `vtable for
> > llvm::cl::opt > std::char_traits,
> > std::allocator >, false,
> > llvm::cl::parser > std::char_traits, std::allocator > > >'
> > /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> > pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> > `llvm::cl::OptionValue > std::char_traits, std::allocator > >::OptionValue()':
> > /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> > default/tmp/work/x86_64-linux/intel-graphics-compiler-
> > native/1.0.11-
> > r0/recipe-sysroot-
> > native/usr/include/llvm/Support/CommandLine.h:601:
> > undefined reference to `vtable for
> > llvm::cl::OptionValue > std::char_traits, std::allocator > >'
> > 

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

Anything ?, I have yet to resolve this.

-Original Message-
From: Monsees, Steven C (US) 
Sent: Wednesday, October 13, 2021 9:03 AM
To: 'Mittal, Anuj' ; 'yocto@lists.yoctoproject.org' 

Subject: RE: [yocto] #zeus meta-intel


Are there any patches required for these components (igc, opencl-clang, and 
intel-compute-runtime) ?

-Original Message-
From: Monsees, Steven C (US) 
Sent: Wednesday, October 13, 2021 7:13 AM
To: 'Mittal, Anuj' ; yocto@lists.yoctoproject.org
Subject: RE: [yocto] #zeus meta-intel


Anuj:

I rebuilt the entire image (but did not delete the state_cache)...
I am building meta-clang (zeus based, I believe it is 9.0.1).

Steve

-Original Message-
From: Mittal, Anuj 
Sent: Tuesday, October 12, 2021 10:10 PM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


Did you build everything with this compiler from start? Is opencl-clang 
building with the right LLVM lib from meta-clang?

Thanks,

Anuj

On Tue, 2021-10-12 at 17:15 +, Monsees, Steven C (US) wrote:
> 
> Anuj:
> 
> I picked up the tarball for for the baseline dunfell tools platform to 
> update host tools...
> 
> I am seeing it compile cleaner but for one issue causng ld to fail:
> 
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> 
> Isn't LLVM brought in along with clang under meta-clang ?
> 
> Is there a missing build dependency ?
> 
> Thanks,
> Steve
> 
> Build excerpt showing multiple " undefined reference to `vtable "
> errors...
> 
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::opt std::char_traits, std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >::~opt()':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::OptionValue std::char_traits, std::allocator > >::OptionValue()':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:601:
> undefined reference to `vtable for
> llvm::cl::OptionValue std::char_traits, std::allocator > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::opt std::char_traits, std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > >
> >::opt llvm::cl::initializer >(llvm::cl::FormattingFlags const&, 
> llvm::cl::desc const&, llvm::cl::initializer const&)':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1407:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::parser std::char_traits, std::allocator >
> >::parser(llvm::cl::Option&)':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1072:
> undefined reference to `vtable for
> llvm::cl::parser std::char_traits, std::allocator > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> 

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

Are there any patches required for these components (igc, opencl-clang, and 
intel-compute-runtime) ?

-Original Message-
From: Monsees, Steven C (US) 
Sent: Wednesday, October 13, 2021 7:13 AM
To: 'Mittal, Anuj' ; yocto@lists.yoctoproject.org
Subject: RE: [yocto] #zeus meta-intel


Anuj:

I rebuilt the entire image (but did not delete the state_cache)...
I am building meta-clang (zeus based, I believe it is 9.0.1).

Steve

-Original Message-
From: Mittal, Anuj 
Sent: Tuesday, October 12, 2021 10:10 PM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


Did you build everything with this compiler from start? Is opencl-clang 
building with the right LLVM lib from meta-clang?

Thanks,

Anuj

On Tue, 2021-10-12 at 17:15 +, Monsees, Steven C (US) wrote:
> 
> Anuj:
> 
> I picked up the tarball for for the baseline dunfell tools platform to 
> update host tools...
> 
> I am seeing it compile cleaner but for one issue causng ld to fail:
> 
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> 
> Isn't LLVM brought in along with clang under meta-clang ?
> 
> Is there a missing build dependency ?
> 
> Thanks,
> Steve
> 
> Build excerpt showing multiple " undefined reference to `vtable "
> errors...
> 
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::opt std::char_traits, std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >::~opt()':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::OptionValue std::char_traits, std::allocator > >::OptionValue()':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:601:
> undefined reference to `vtable for
> llvm::cl::OptionValue std::char_traits, std::allocator > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::opt std::char_traits, std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > >
> >::opt llvm::cl::initializer >(llvm::cl::FormattingFlags const&, 
> llvm::cl::desc const&, llvm::cl::initializer const&)':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1407:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::parser std::char_traits, std::allocator >
> >::parser(llvm::cl::Option&)':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1072:
> undefined reference to `vtable for
> llvm::cl::parser std::char_traits, std::allocator > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::opt std::char_traits, std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >::~opt()':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> 

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

Anuj:

I rebuilt the entire image (but did not delete the state_cache)...
I am building meta-clang (zeus based, I believe it is 9.0.1).

Steve

-Original Message-
From: Mittal, Anuj  
Sent: Tuesday, October 12, 2021 10:10 PM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


Did you build everything with this compiler from start? Is opencl-clang 
building with the right LLVM lib from meta-clang?

Thanks,

Anuj

On Tue, 2021-10-12 at 17:15 +, Monsees, Steven C (US) wrote:
> 
> Anuj:
> 
> I picked up the tarball for for the baseline dunfell tools platform to 
> update host tools...
> 
> I am seeing it compile cleaner but for one issue causng ld to fail:
> 
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> 
> Isn't LLVM brought in along with clang under meta-clang ?
> 
> Is there a missing build dependency ?
> 
> Thanks,
> Steve
> 
> Build excerpt showing multiple " undefined reference to `vtable "
> errors...
> 
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::opt std::char_traits, std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >::~opt()':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::OptionValue std::char_traits, std::allocator > >::OptionValue()':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:601:
> undefined reference to `vtable for
> llvm::cl::OptionValue std::char_traits, std::allocator > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::opt std::char_traits, std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > >
> >::opt llvm::cl::initializer >(llvm::cl::FormattingFlags const&, 
> llvm::cl::desc const&, llvm::cl::initializer const&)':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1407:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::parser std::char_traits, std::allocator >
> >::parser(llvm::cl::Option&)':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1072:
> undefined reference to `vtable for
> llvm::cl::parser std::char_traits, std::allocator > >'
> /opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
> pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
> IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
> `llvm::cl::opt std::char_traits, std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >::~opt()':
> /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
> default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-
> r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
> undefined reference to `vtable for
> llvm::cl::opt, 
> std::allocator >, false, 
> llvm::cl::parser std::char_traits, std::allocator > > >'
> 

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

Anuj:

I picked up the tarball for for the baseline dunfell tools platform to update 
host tools...

I am seeing it compile cleaner but for one issue causng ld to fail:

/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
 undefined reference to `vtable for 
llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >'

Isn't LLVM brought in along with clang under meta-clang ?

Is there a missing build dependency ?

Thanks,
Steve

Build excerpt showing multiple " undefined reference to `vtable " errors...

/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
 IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
`llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
 undefined reference to `vtable for 
llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
 IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
`llvm::cl::OptionValue, 
std::allocator > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:601:
 undefined reference to `vtable for 
llvm::cl::OptionValue, 
std::allocator > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
 IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
`llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >::opt >(llvm::cl::FormattingFlags const&, 
llvm::cl::desc const&, llvm::cl::initializer const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1407:
 undefined reference to `vtable for 
llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
 IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
`llvm::cl::parser, 
std::allocator > >::parser(llvm::cl::Option&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1072:
 undefined reference to `vtable for 
llvm::cl::parser, 
std::allocator > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
 IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
`llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1331:
 undefined reference to `vtable for 
llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
 IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
`llvm::cl::OptionValue, 
std::allocator > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:601:
 undefined reference to `vtable for 
llvm::cl::OptionValue, 
std::allocator > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
 IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 
`llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >::opt(char const (&) [9], 
llvm::cl::desc const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include/llvm/Support/CommandLine.h:1407:
 undefined reference to `vtable for 
llvm::cl::opt, 
std::allocator >, false, 
llvm::cl::parser, 
std::allocator > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
 IGC/ElfPackager/CMakeFiles/elf_packager.dir/main.cpp.o: in function 

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

For this test case I was only building in opencl-clang and igc...

If I attempt to build in intel-compute-runtime, iy attempts to make use of igc 
and I see the following build issue:

08:11 smonsees@yix490031 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default>bitbake 
intel-compute-runtime
Loading cache: 100% 
|##|
 Time: 0:00:00
Loaded 3672 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.44.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "rhel-7.9"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "sbcb-default"
DISTRO   = "limws"
DISTRO_VERSION   = "3.0.4"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta 
meta-poky= "my_yocto_3.0.4:9662755c328d9406cccb206f6e67945f6894789b"
meta-perl
meta-python  
meta-filesystems 
meta-networking  
meta-initramfs   
meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-clang   = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel   = 
"LIMWSSWARE-423-oews-meta-bae-merge:fa33549eca95293aeec58bf0624b3315c08fdba0"

Initialising tasks: 100% 
|#|
 Time: 0:00:01
Checking sstate mirror object availability: 100% 
|#| 
Time: 0:00:00
Sstate summary: Wanted 176 Found 166 Missed 10 Current 284 (94% match, 97% 
complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: intel-graphics-compiler-native-1.0.11-r0 do_compile: Execution of 
'/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/temp/run.do_compile.26870'
 failed with exit code 1:
[1/565] cd 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/visa
 && 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/bin/flex
 -PCISA 
-o/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/build/IGC/visa/lex.CISA.cpp
 CISA.l
CISA.l:486: warning, rule cannot be matched
[2/565] cd 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/build/IGC/BiFModule
 && 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/bin/cmake
 -E make_directory 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/build/IGC/Release/bif/.
 && 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/python3
 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/BiFModule/concat.py
 -new 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/build/IGC/Release/bif/./opencl_cth.h
 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/BiFModule/Languages/OpenCL/opencl_cth_released.h
 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/BiFModule/Languages/OpenCL/PreRelease/opencl_cth_pre_release.h
[3/565] cd 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/build/IGC/autogen/MDAutogen
 && 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/python3
 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common/autogen.py
 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common/MDFrameWork.h
 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/build/IGC/autogen/MDNodeFunctions.gen
[4/565] cd 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/build/IGC/GenISAIntrinsics
 && 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/python3
 

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

Anuj:

Are there any other possible dependencies for the 
“meta-intel/dynamic-layers/clang-layer/recipes-
opencl” ?

Is this dependent on systemd ?

It appears to builds clean, but fails/faults while booting kernel...

Thanks again,
Steve

-Original Message-
From: Mittal, Anuj  
Sent: Friday, October 8, 2021 11:05 PM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


On Fri, 2021-10-08 at 16:10 +, Monsees, Steven C (US) via 
lists.yoctoproject.org wrote:
> 
> Sorry for my ignorance, but I am missing your point, what exactly does 
> the recipe provide when built, intel-opencl-icd ?, will it pull in igc 
> ?

It will pull in igc. There's a separate recipe for igc in meta-intel.
compute-runtime will provide intel-opencl-icd but the package name is different.

You can try building the recipe.

Thanks,

Anuj

> 
> -Original Message-
> From: Mittal, Anuj 
> Sent: Friday, October 8, 2021 12:01 PM
> To: Monsees, Steven C (US) ; 
> yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #zeus meta-intel
> 
> External Email Alert
> 
> This email has been sent from an account outside of the BAE Systems 
> network.
> 
> Please treat the email with caution, especially if you are requested 
> to click on a link, decrypt/open an attachment, or enable macros.
> For further information on how to spot phishing, access “Cybersecurity 
> OneSpace Page” and report phishing by clicking the button “Report 
> Phishing” on the Outlook toolbar.
> 
> 
> Sorry, I didn't understand the question. If you want to know which 
> version of OpenCL is supported, please see the README for version that 
> you're building. Also see:
> 
> https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md
> 
> Thanks,
> 
> Anuj
> 
> On Fri, 2021-10-08 at 15:30 +, Monsees, Steven C (US) wrote:
> > 
> > Thank you, just for clarification ...
> > 
> > "Building the Neo driver", does that mean no OpenCL library support 
> > ?
> > 
> > -Original Message-
> > From: Mittal, Anuj 
> > Sent: Friday, October 8, 2021 11:07 AM
> > To: Monsees, Steven C (US) ; 
> > yocto@lists.yoctoproject.org
> > Subject: Re: [yocto] #zeus meta-intel
> > 
> > External Email Alert
> > 
> > This email has been sent from an account outside of the BAE Systems 
> > network.
> > 
> > Please treat the email with caution, especially if you are requested 
> > to click on a link, decrypt/open an attachment, or enable macros.
> > For
> > further information on how to spot phishing, access “Cybersecurity 
> > OneSpace Page” and report phishing by clicking the button “Report 
> > Phishing” on the Outlook toolbar.
> > 
> > 
> > On Thu, 2021-10-07 at 16:20 +, Monsees, Steven C (US) via 
> > lists.yoctoproject.org wrote:
> > >  
> > >  
> > > I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
> > > opencl/compute-runtime”
> > > I have been “told” that this compute-runtime recipe should 
> > > basically build opencl (Neo) with all the required dependencies… I 
> > > did not think Yocto had support for OpenCL, and was looking to 
> > > build Neo under the SDK.
> > >  
> > > (1)   Is this true, does meta-intell under zeus now support 
> > > building OpenCL and the OpenCL Graphics compiler under Yocto ?
> > 
> > compute-runtime recipe would allow you to build NEO driver. zeus is 
> > no longer maintained so the version there is old and not tested now 
> > but it should still build.
> > 
> > > (2)   Of so, what would be the proper way to pull this into my 
> > > yocto build ?
> > 
> > Including meta-intel and meta-clang in bblayers should be enough.
> > 
> > Thanks,
> > 
> > Anuj
> 
> 
> 
> 


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

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

Sorry for my ignorance, but I am missing your point, what exactly does the 
recipe provide when built, intel-opencl-icd ?, will it pull in igc ?

-Original Message-
From: Mittal, Anuj  
Sent: Friday, October 8, 2021 12:01 PM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


Sorry, I didn't understand the question. If you want to know which version of 
OpenCL is supported, please see the README for version that you're building. 
Also see:

https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md

Thanks,

Anuj

On Fri, 2021-10-08 at 15:30 +, Monsees, Steven C (US) wrote:
> 
> Thank you, just for clarification ...
> 
> "Building the Neo driver", does that mean no OpenCL library support ?
> 
> -Original Message-
> From: Mittal, Anuj 
> Sent: Friday, October 8, 2021 11:07 AM
> To: Monsees, Steven C (US) ; 
> yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #zeus meta-intel
> 
> External Email Alert
> 
> This email has been sent from an account outside of the BAE Systems 
> network.
> 
> Please treat the email with caution, especially if you are requested 
> to click on a link, decrypt/open an attachment, or enable macros.  For 
> further information on how to spot phishing, access “Cybersecurity 
> OneSpace Page” and report phishing by clicking the button “Report 
> Phishing” on the Outlook toolbar.
> 
> 
> On Thu, 2021-10-07 at 16:20 +, Monsees, Steven C (US) via 
> lists.yoctoproject.org wrote:
> >  
> >  
> > I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
> > opencl/compute-runtime”
> > I have been “told” that this compute-runtime recipe should basically 
> > build opencl (Neo) with all the required dependencies… I did not 
> > think Yocto had support for OpenCL, and was looking to build Neo 
> > under the SDK.
> >  
> > (1)   Is this true, does meta-intell under zeus now support building 
> > OpenCL and the OpenCL Graphics compiler under Yocto ?
> 
> compute-runtime recipe would allow you to build NEO driver. zeus is no 
> longer maintained so the version there is old and not tested now but 
> it should still build.
> 
> > (2)   Of so, what would be the proper way to pull this into my yocto 
> > build ?
> 
> Including meta-intel and meta-clang in bblayers should be enough.
> 
> Thanks,
> 
> Anuj


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

Re: [yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thank you, just for clarification ...

"Building the Neo driver", does that mean no OpenCL library support ?

-Original Message-
From: Mittal, Anuj  
Sent: Friday, October 8, 2021 11:07 AM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


On Thu, 2021-10-07 at 16:20 +0000, Monsees, Steven C (US) via 
lists.yoctoproject.org wrote:
>  
>  
> I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-
> opencl/compute-runtime”
> I have been “told” that this compute-runtime recipe should basically 
> build opencl (Neo) with all the required dependencies… I did not think 
> Yocto had support for OpenCL, and was looking to build Neo under the 
> SDK.
>  
> (1)   Is this true, does meta-intell under zeus now support building 
> OpenCL and the OpenCL Graphics compiler under Yocto ?

compute-runtime recipe would allow you to build NEO driver. zeus is no longer 
maintained so the version there is old and not tested now but it should still 
build.

> (2)   Of so, what would be the proper way to pull this into my yocto 
> build ?

Including meta-intel and meta-clang in bblayers should be enough.

Thanks,

Anuj

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

[yocto] #zeus meta-intel

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am looking at 
"meta-intel/dynamic-layers/clang-layer/recipes-opencl/compute-runtime"
I have been "told" that this compute-runtime recipe should basically build 
opencl (Neo) with all the required dependencies...
I did not think Yocto had support for OpenCL, and was looking to build Neo 
under the SDK.


(1)Is this true, does meta-intell under zeus now support building OpenCL 
and the OpenCL Graphics compiler under Yocto ?

(2)Of so, what would be the proper way to pull this into my yocto build ?

Thanks,
Steve

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

[yocto] #yocto -third party licensimg

[Monsees, Steven C (US) via lists.yoctoproject.org]

Hello:

I am running zeus 3.0.4...

A vendor has supplied us with a generic license.txt file, which we were able to 
add to the acexpci recipe we use to build in their package.
The license provided to us by the vendor is not part of the generic licenses 
list that yocto recognizes.

We get a warning though which says:

WARNING: aiox-defaultfs-1.0-r0 do_rootfs: The license listed 
DataDeviceCorporation was not in the licenses collected for recipe acexpci

Though the warning occurs, I can see the license.txt being saved inside the 
rootfs on and is saved under tmp/deploy/licenses/acexpci.
I've been trying to get rid of this warning when the image builds, but I can't 
seem to find anything in the manuals or online.

The one solution I found says : Add LICENSE_PATH += 
"${LAYERDIR}/custom-licenses" under conf/layer.conf, this does not resolve this 
warning.

This is a new item being added to our Yocto build.
The Data Direct vendor does not submit their code to Yocto because they sell 
thier code.
We are adding code to Yocto that has a private license and we are attempting to 
have Yocto accept the license, is this proper way to handle this ?

Can you tell me the proper way to add a custom license to a recipe in yocto ?

Thanks,
Steve

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

Re: [yocto] # yocto Fatal QA error (LIC_FILES_CHKSUM) [license-checksum]

[Monsees, Steven C (US) via lists.yoctoproject.org]

Never mind this, I worked it out…  thanks anyway.

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, August 25, 2021 12:25 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] # yocto Fatal QA error (LIC_FILES_CHKSUM) [license-checksum]

External Email Alert

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



Using zeus, and I am build an image with no issues...

I then want to tweak the configuration by pulling in an a ".cfg" file to be 
able to tweak options depending on use…

I add the following to the image ".bb" file:

FILESEXTRAPATHS_prepend := "$THISDIR:"
SRC_URI += "file://sbcb-defaultfs-swdebug.cfg"


sbcb-defaultfs-swdebug.cfg consists of three lines:

CONFIG_KPROBES=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_DEBUG_INFO=y

When I add the above I see the following build issue, how do I relove this ?

ERROR: sbcb-defaultfs-swdebug-1.0-r0 do_populate_lic: QA Issue: 
sbcb-defaultfs-swdebug: Recipe file fetches files and does not have license 
file information (LIC_FILES_CHKSUM) [license-checksum]
ERROR: sbcb-defaultfs-swdebug-1.0-r0 do_populate_lic: Fatal QA errors found, 
failing task.
ERROR: Logfile of failure stored in: 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-swdebug/1.0-r0/temp/log.do_populate_lic.29324
ERROR: Task 
(/disk0/scratch/smonsees/yocto/workspace_1/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-swdebug.bb:do_populate_lic)
 failed with exit code '1'

Thanks,
Steve

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

[yocto] # yocto Fatal QA error (LIC_FILES_CHKSUM) [license-checksum]

[Monsees, Steven C (US) via lists.yoctoproject.org]

Using zeus, and I am build an image with no issues...

I then want to tweak the configuration by pulling in an a ".cfg" file to be 
able to tweak options depending on use...

I add the following to the image ".bb" file:

FILESEXTRAPATHS_prepend := "$THISDIR:"
SRC_URI += "file://sbcb-defaultfs-swdebug.cfg"


sbcb-defaultfs-swdebug.cfg consists of three lines:

CONFIG_KPROBES=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_DEBUG_INFO=y

When I add the above I see the following build issue, how do I relove this ?

ERROR: sbcb-defaultfs-swdebug-1.0-r0 do_populate_lic: QA Issue: 
sbcb-defaultfs-swdebug: Recipe file fetches files and does not have license 
file information (LIC_FILES_CHKSUM) [license-checksum]
ERROR: sbcb-defaultfs-swdebug-1.0-r0 do_populate_lic: Fatal QA errors found, 
failing task.
ERROR: Logfile of failure stored in: 
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-swdebug/1.0-r0/temp/log.do_populate_lic.29324
ERROR: Task 
(/disk0/scratch/smonsees/yocto/workspace_1/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-swdebug.bb:do_populate_lic)
 failed with exit code '1'

Thanks,
Steve

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

Re: [yocto] #yocto debbuging option under zeus

[Monsees, Steven C (US) via lists.yoctoproject.org]

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

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

External Email Alert

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



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

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

[trz@empanada core2]$ scp 
/home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2r2.core2_32.rpm
 root@192.168.1.31<mailto:root@192.168.1.31>:
 root@192.168.1.31's<mailto:root@192.168.1.31's> password:
 busybox-dbg-1.20.2-r2.core2_32.rpm 100% 1826KB   
1.8MB/s   00:01

Now install the debug rpm on the target:
 root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm
“

Thanks,
Steve

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

[yocto] #yocto debbuging option under zeus

[Monsees, Steven C (US) via lists.yoctoproject.org]

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

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

[trz@empanada core2]$ scp 
/home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2r2.core2_32.rpm
 root@192.168.1.31:
 root@192.168.1.31's password:
 busybox-dbg-1.20.2-r2.core2_32.rpm 100% 1826KB   
1.8MB/s   00:01

Now install the debug rpm on the target:
 root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm
"

Thanks,
Steve

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

Re: [yocto] #yocto -kernel startup of devices/platform/amba/ffa00000.perf-monitor

[Monsees, Steven C (US) via lists.yoctoproject.org]

Nevermind I found it, long day…

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, July 28, 2021 1:57 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] #yocto -kernel startup of 
devices/platform/amba/ffa0.perf-monitor

External Email Alert

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



I am running with zeus…, during kernel startup I see perf-monitors setup

[3.564635] xilinx-axipmon ffa0.perf-monitor: Probed Xilinx APM
[3.571139] xilinx-axipmon fd0b.perf-monitor: Probed Xilinx APM
[3.577571] xilinx-axipmon fd49.perf-monitor: Probed Xilinx APM
[3.583987] xilinx-axipmon ffa1.perf-monitor: Probed Xilinx APM

Are these are tied to uio0 thru uio3 ?
Can someone tell me what recipe initializes and brings these in ?
Is it possible to delay their initialization/startup ?
(I would like to have them come into play after I setup the uio_fpga interrupt…)

root@cvpx-default ls -la /sys/class/uio
total 0
drwxr-xr-x  2 root root 0 Jan  1  1970 .
drwxr-xr-x 49 root root 0 Jan  1  1970 ..
lrwxrwxrwx  1 root root 0 Jan  1  1970 uio0 -> 
../../devices/platform/amba/ffa0.perf-monitor/uio/uio0
lrwxrwxrwx  1 root root 0 Jan  1  1970 uio1 -> 
../../devices/platform/amba/fd0b.perf-monitor/uio/uio1
lrwxrwxrwx  1 root root 0 Jan  1  1970 uio2 -> 
../../devices/platform/amba/fd49.perf-monitor/uio/uio2
lrwxrwxrwx  1 root root 0 Jan  1  1970 uio3 -> 
../../devices/platform/amba/ffa1.perf-monitor/uio/uio3
lrwxrwxrwx  1 root root 0 Jul 28 17:36 uio4 -> ../../devices/uio_fpga/uio/uio4
root@cvpx-default

Thanks,
Steve

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

[yocto] #yocto -kernel startup of devices/platform/amba/ffa00000.perf-monitor

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am running with zeus..., during kernel startup I see perf-monitors setup

[3.564635] xilinx-axipmon ffa0.perf-monitor: Probed Xilinx APM
[3.571139] xilinx-axipmon fd0b.perf-monitor: Probed Xilinx APM
[3.577571] xilinx-axipmon fd49.perf-monitor: Probed Xilinx APM
[3.583987] xilinx-axipmon ffa1.perf-monitor: Probed Xilinx APM

Are these are tied to uio0 thru uio3 ?
Can someone tell me what recipe initializes and brings these in ?
Is it possible to delay their initialization/startup ?
(I would like to have them come into play after I setup the uio_fpga 
interrupt...)
root@cvpx-default ls -la /sys/class/uio
total 0
drwxr-xr-x  2 root root 0 Jan  1  1970 .
drwxr-xr-x 49 root root 0 Jan  1  1970 ..
lrwxrwxrwx  1 root root 0 Jan  1  1970 uio0 -> 
../../devices/platform/amba/ffa0.perf-monitor/uio/uio0
lrwxrwxrwx  1 root root 0 Jan  1  1970 uio1 -> 
../../devices/platform/amba/fd0b.perf-monitor/uio/uio1
lrwxrwxrwx  1 root root 0 Jan  1  1970 uio2 -> 
../../devices/platform/amba/fd49.perf-monitor/uio/uio2
lrwxrwxrwx  1 root root 0 Jan  1  1970 uio3 -> 
../../devices/platform/amba/ffa1.perf-monitor/uio/uio3
lrwxrwxrwx  1 root root 0 Jul 28 17:36 uio4 -> ../../devices/uio_fpga/uio/uio4
root@cvpx-default

Thanks,
Steve

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

Re: [yocto] #yocto

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks...


-Original Message-
From: Ross Burton  
Sent: Tuesday, July 20, 2021 5:03 AM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto

External Email Alert

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

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


Not deleting the source tree is the default behaviour.  It sounds like you've 
inherited rm_work, so if you want to not delete build trees after completion 
then add the recipe name to RM_WORK_EXCLUDE.

Ross

On Mon, 19 Jul 2021 at 15:22, Monsees, Steven C (US) via lists.yoctoproject.org 
 wrote:
>
>
>
> What flag do I set in order to keep the source code for a recipe being built 
> within the build tree after compilation  ?
>
>
>
> Thanks,
>
> Steve
>
>
> 
>

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

[yocto] #yocto

[Monsees, Steven C (US) via lists.yoctoproject.org]

What flag do I set in order to keep the source code for a recipe being built 
within the build tree after compilation  ?

Thanks,
Steve

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

[yocto] #yocto #zeus

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am running with zeus 3.0.4 and appear to have an issue with the mount command 
supporting NFS... ?

Can someone explain the following and how I can get "mount" to support NFS ?

Trying to mount the UDM from the AIO
mount.nfs: Operation not permitted
Failed to mount the UDM from the AIO!
Trying tNFS: bad mount option value specified: minorversion=1

Thanks,
Steve

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

[yocto] kernel init debug features

[Monsees, Steven C (US) via lists.yoctoproject.org]

I have kernels based off "rocko" and "zeus" for both Arm and Intel... all using 
sysvinit (not systemd).

Under the Yocto build system, how can I easily set the following kernel 
configuration variables based on the build for testing/debug ?


*sched_rt_period_us

*sched_rt_runtime_us

*overcommit_memory

thanks,
Steve

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

[yocto] PREEMPT_RT patches

[Monsees, Steven C (US) via lists.yoctoproject.org]

Recently I heard somewhere that newer versions of the Linux Kernel will include 
the PREEMPT_RT patches, and configuration settings would be used to set how the 
Linux would operate in a specific system.

Does Yocto support "PREEMPT_RT", and what versions of Yocto have this option ?

Is there documentation on this feature/option ?

Thanks,
Steve


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

Re: [yocto] #yocto cmake configurations

[Monsees, Steven C (US) via lists.yoctoproject.org]

efined reference to `clang::Decl::getAttrs() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
 in function `clang::CodeGen::CodeGenModule::Release()':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520:
 undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) 
const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
 in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788:
 undefined reference to 
`clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl 
const*, llvm::function_ref) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819:
 undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
 in function 
`clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
 undefined reference to 
`clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
 undefined reference to 
`clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
 undefined reference to 
`clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
 in function `clang::Module::getTopLevelModuleName() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468:
 undefined reference to `clang::Module::getTopLevelModule() const'


From: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>; Khem Raj 
mailto:raj.k...@gmail.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: RE: [yocto] #yocto cmake configurations


All the libraries are under the SDK here:

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

I need the DRM libraries to be picked up correctly, libclang.so may not be 
required since I have all the static variations available, (added to while 
testing linker) I have yet to make it through entire build due to linker issue…

Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj mailto:raj.k...@gmail.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment

Re: [yocto] #yocto cmake configurations

[Monsees, Steven C (US) via lists.yoctoproject.org]

ratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788:
 undefined reference to 
`clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl 
const*, llvm::function_ref) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819:
 undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
 in function 
`clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
 undefined reference to 
`clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
 undefined reference to 
`clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188:
 undefined reference to 
`clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o):
 in function `clang::Module::getTopLevelModuleName() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468:
 undefined reference to `clang::Module::getTopLevelModule() const'


From: Monsees, Steven C (US) 
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) ; Khem Raj 

Cc: yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto cmake configurations


All the libraries are under the SDK here:

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

I need the DRM libraries to be picked up correctly, libclang.so may not be 
required since I have all the static variations available, (added to while 
testing linker) I have yet to make it through entire build due to linker 
issue...

Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj mailto:raj.k...@gmail.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



Khem:

I only have the following libraries present for these:

libclang.so
libclang.so.9
libdrm_intel.so
libdrm_intel.so.1
libdrm_intel.so.1.0.0
libdrm.so
libdrm.so.2
libdrm.so.2.4.0

I do generate the static (*.a) files for both LLVM & Clang and they appear to 
all be present (No libclang.a was generated).

Steve

From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by

Re: [yocto] #yocto cmake configurations

[Monsees, Steven C (US) via lists.yoctoproject.org]

All the libraries are under the SDK here:

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

I need the DRM libraries to be picked up correctly, libclang.so may not be 
required since I have all the static variations available, (added to while 
testing linker) I have yet to make it through entire build due to linker 
issue...

Steve

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



Khem:

I only have the following libraries present for these:

libclang.so
libclang.so.9
libdrm_intel.so
libdrm_intel.so.1
libdrm_intel.so.1.0.0
libdrm.so
libdrm.so.2
libdrm.so.2.4.0

I do generate the static (*.a) files for both LLVM & Clang and they appear to 
all be present (No libclang.a was generated).

Steve

From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if 
you have libclang.a libdrm_intel.a and libdrm.a ?

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:
Yes, LLVM & Clang...

From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:

Attached...

From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:

My standard zeus SDK appears to have an issue linking in my applications 
dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -lclang
collect2: error: ld returned 1 exit st

Re: [yocto] #yocto cmake configurations

[Monsees, Steven C (US) via lists.yoctoproject.org]

Khem:

I only have the following libraries present for these:

libclang.so
libclang.so.9
libdrm_intel.so
libdrm_intel.so.1
libdrm_intel.so.1.0.0
libdrm.so
libdrm.so.2
libdrm.so.2.4.0

I do generate the static (*.a) files for both LLVM & Clang and they appear to 
all be present (No libclang.a was generated).

Steve

From: Khem Raj 
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if 
you have libclang.a libdrm_intel.a and libdrm.a ?

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:
Yes, LLVM & Clang...

From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:

Attached...

From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:

My standard zeus SDK appears to have an issue linking in my applications 
dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld...

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} 
-L$ENV{OECORE_TARGET_SYSROOT}/usr/lib 
-L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread 
-pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of -L's...

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, 

Re: [yocto] #yocto cmake configurations

[Monsees, Steven C (US) via lists.yoctoproject.org]

Yes, LLVM & Clang...

From: Khem Raj 
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


I see its using -rdynamic -static
so next question is that do you have .a files in your sdk ?

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:

Attached...

From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) 
mailto:steven.mons...@baesystems.com>>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:

My standard zeus SDK appears to have an issue linking in my applications 
dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld...

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} 
-L$ENV{OECORE_TARGET_SYSROOT}/usr/lib 
-L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread 
-pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of -L's...

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for 
find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup 
for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when 
doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53380): https://lists.yoctoproject.org/g/yocto/message/53380
Mute This Topic: https://lists.yoctoproject.org/mt/825

Re: [yocto] #yocto cmake configurations

[Monsees, Steven C (US) via lists.yoctoproject.org]

Attached...

From: Khem Raj 
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


can you post full linker cmd which is failing ?

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:baesystems@lists.yoctoproject.org>>
 wrote:

My standard zeus SDK appears to have an issue linking in my applications 
dynamic libs...

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld...

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} 
-L$ENV{OECORE_TARGET_SYSROOT}/usr/lib 
-L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread 
-pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of -L's...

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Monsees, Steven C (US) via 
lists.yoctoproject.org<http://lists.yoctoproject.org>
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: [yocto] #yocto cmake configurations

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.



I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for 
find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup 
for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when 
doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve


/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++
  
--sysroot=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux
 -O2 -pipe -g -feliminate-unused-debug-types   -funroll-loops -fstrict-aliasing 
-msse2 -msse3 -mssse3 -msse4.1 -fPIC -Wall -mfpmath=sse -Wcast-align  
-std=c++0x -Wno-invalid-offsetof -fno-rtti 
-I/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/include
 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -DGBE_DEBUG_MEMORY=0  -DGBE_COMPILER_AVAILABLE=1 
-fvisibility=hidden -O0 -g -DGBE_DEBUG=1  
--sysroot=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux
 
-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib
 
-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/x86_64-poky-linux/9.2.0
 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu 
-Wl,--as-needed -rdynamic -static 
CMakeFiles/gbe_bin_generater.dir/gbe_bin_generater.cpp.o 
CMakeFiles/gbe_bin_generater.dir/sys/intrusive_list.cpp.o 
CMakeFiles/gbe_bin_genera

Re: [yocto] #yocto cmake configurations

[Monsees, Steven C (US) via lists.yoctoproject.org]

My standard zeus SDK appears to have an issue linking in my applications 
dynamic libs…

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm_intel
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -ldrm
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld:
 cannot find -lclang
collect2: error: ld returned 1 exit status
The libraries are under: 
/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

My CMake build app does not appear to have an issue finding the files:

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so
DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

It appears to be an issue specifically with the ld…

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} 
-L$ENV{OECORE_TARGET_SYSROOT}/usr/lib 
-L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread 
-pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

It does not appear to be making use of –L’s…

Is there something I might look at/configure (i.e. add paths to search paths) ?
Is there a simple test to validate tool ?

Thanks,
Steve

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] #yocto cmake configurations

External Email Alert

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



I am using zeus, standard SDK, cmake…

Can I pre-configure the SDK to setup cmake package search paths ?, say for 
find_package, etc. (i.e. detecting external libraries/programs)…

The majority of my env is configuring properly, but I am finding cmake is setup 
for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when 
doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve

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

[yocto] #yocto cmake configurations

[Monsees, Steven C (US) via lists.yoctoproject.org]

I am using zeus, standard SDK, cmake...

Can I pre-configure the SDK to setup cmake package search paths ?, say for 
find_package, etc. (i.e. detecting external libraries/programs)...

The majority of my env is configuring properly, but I am finding cmake is setup 
for a standard linux env with regards to these types of searches, and
I wanted the cmake built in to look at my SDK paths (first by default) when 
doing such things as detecting python interpreter, libraries, etc.

I am working on third party package unaware of my SDK setup.

Thanks,
Steve

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

[yocto] #yocto opencl

[Monsees, Steven C (US) via lists.yoctoproject.org]

Can someone tell me is this supported under Yocto in any way?

meta-beignet/recipes-opencl at ross * rossburton/meta-beignet * 
GitHub

Any docs, or updates ?

Wanted to know if this would work under Zeus, with meta-clang ?
Looking to build opencl shared library support...

Thanks,
Steve

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

Re: [yocto] #yocto #sdk #cmake

[Monsees, Steven C (US) via lists.yoctoproject.org]

Thanks you...

-Original Message-
From: Khem Raj  
Sent: Thursday, April 22, 2021 11:23 PM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk #cmake

External Email Alert

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

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


take a look at
https://github.com/kraj/meta-clang/blob/master/recipes-core/meta/clang-environment.inc#L11-L19

perhaps that can be something you might find useful

On Thu, Apr 22, 2021 at 11:51 AM Monsees, Steven C (US) via 
lists.yoctoproject.org  
wrote:
>
>
>
> When setting up an SDK, (standard or extensible),  build which will be using 
> cmake, is there a proper way to pre-configure OEToolchainConfig.cmake for 
> ones env/applications ?
>
>
>
> Currently I build the SDK, install, and then manually edit...
>
>
>
> Thanks,
>
> Steve
>
>
> 
>

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

[yocto] #yocto #sdk #cmake

[Monsees, Steven C (US) via lists.yoctoproject.org]

When setting up an SDK, (standard or extensible),  build which will be using 
cmake, is there a proper way to pre-configure OEToolchainConfig.cmake for ones 
env/applications ?

Currently I build the SDK, install, and then manually edit...

Thanks,
Steve

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

Re: [yocto] #yocto llvm support and meta-clang

[Monsees, Steven C (US) via lists.yoctoproject.org]

Khem:

There are at least 4 zeus released tags, can you vouch for one of them to work 
properly with meta-clang ?
Porting to dunfell might not be possible at this time...

Would it be possible to build the dunfell drop of meta-clang under zeus ?


Although we do not plan on using clang in the kernel, I did a quick build to 
see if I would get a similar error...
Seeing: error: unknown argument: '-maccumulate-outgoing-args' for kernel build

Any ideas what might be missing ?

Again Note: If I remove/comment out the line TOOLCHAIN ?= "clang" in 
conf/local.conf, the build is much faster,
and it builds without the error, also appears not to require/include "llvm" 
component in build.
I do not believe the full package was actually built/enabled, but no errors and 
image is functional.

Steps used to build a clean Kernel image with meta-clang...

(1) Added meta-clang to bblayers.conf

(2) Added Setting for meta-clang in conf/local.conf:

TOOLCHAIN ?= "clang"

The build is much slower due to "clang-native-9.0.1-r0 do_compile"...

EXT SDK build error seen:
=

13:36 smonsees@yix490038 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default> bitbake -k 
sbcb-defaultfs-fullParsing recipes: 100% 
|#|
 Time: 0:01:27
Parsing of 2463 .bb files complete (0 cached, 2463 parsed). 3671 targets, 91 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.44.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "rhel-7.9"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "sbcb-default"
DISTRO   = "limws"
DISTRO_VERSION   = "3.0.4"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta 
meta-poky= "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
meta-perl
meta-python
meta-filesystems 
meta-networking
meta-initramfs   
meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-clang   = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel   = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

Initialising tasks: 100% 
|##|
 Time: 0:00:05
Checking sstate mirror object availability: 100% 
|##| Time: 0:00:01
Sstate summary: Wanted 2137 Found 709 Missed 1428 Current 0 (33% match, 0% 
complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: gnu-efi-3.0.9-r0 do_compile: oe_runmake failed
ERROR: gnu-efi-3.0.9-r0 do_compile: Execution of 
'/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/temp/run.do_compile.1840'
 failed with exit code 1:
mkdir -p 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9/x86_64/lib
make -C 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9/x86_64/lib
 -f 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9//lib/Makefile
 
SRCDIR=/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9//lib
 ARCH=x86_64
make[1]: Entering directory 
`/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9/x86_64/lib'
for sdir in ia32 x86_64 ia64 aarch64 arm mips64el runtime; do mkdir -p $sdir; 
done
x86_64-poky-linux-clang  -m64 -march=nehalem -mtune=generic  -msse4.2   
-mlittle-endian -Wno-error=unused-command-line-argument -Qunused-arguments 
--sysroot=/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/recipe-sysroot
 
-I/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9//lib
 
-I/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9//lib/../inc
 
-I/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9//lib/../inc/x86_64
 
-I/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0/gnu-efi-3.0.9//lib/../inc/protocol
  -O2 -pipe -g -feliminate-unused-debug-types 
-fmacro-prefix-map=/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/gnu-efi/3.0.9-r0=/usr/src/debug/gnu-efi/3.0.9-r0
  

Re: [yocto] #yocto llvm support and meta-clang

[Monsees, Steven C (US) via lists.yoctoproject.org]

ib'

ERROR: Logfile of failure stored in: 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/temp/log.do_sdk_depends.24732
ERROR: Task 
(/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_sdk_depends)
 failed with exit code '1'
NOTE: Tasks Summary: Attempted 6892 tasks of which 5539 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:
  
/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_sdk_depends
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
13:01 smonsees@yix490038 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default>



Note: Modifying SDK_EXTRA_TOOLS by removing "nativesdk-clang", i.e.:

SDK_EXTRA_TOOLS = "  \
nativesdk-cmake \
"

If I remove, the build is much faster, and it builds without the error, also 
appears not to require/include 
"llvm" component in build.
I do not believe the full package was actually built/enabled, but no errors and 
image is functional.


13:09 smonsees@yix490038 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default> bitbake 
sbcb-defaultfs-full -c populate_sdk_ext
Parsing recipes: 100% 
|#|
 Time: 0:01:26
Parsing of 2463 .bb files complete (0 cached, 2463 parsed). 3671 targets, 91 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.44.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "rhel-7.9"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "sbcb-default"
DISTRO   = "limws"
DISTRO_VERSION   = "3.0.4"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta 
meta-poky= "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
meta-perl
meta-python
meta-filesystems 
meta-networking
meta-initramfs   
meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-clang   = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel   = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

NOTE: Fetching uninative binary shim from 
file:///ede/tms/yocto/zeus/downloads/intel/x86_64-nativesdk-libc.tar.xz;sha256sum=a09922172c3a439105e0ae6b943daad2d83505b17da0aba97961ff433b8c21ab
Initialising tasks: 100% 
|##|
 Time: 0:00:12
Checking sstate mirror object availability: 100% 
|##| Time: 0:00:00
Sstate summary: Wanted 2436 Found 2407 Missed 29 Current 0 (98% match, 0% 
complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
NOTE: Tasks Summary: Attempted 6767 tasks of which 6223 didn't need to be rerun 
and all succeeded.
13:31 smonsees@yix490038 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default>


-Original Message-
From: Khem Raj  
Sent: Tuesday, April 20, 2021 12:02 PM
To: Monsees, Steven C (US) ; Anton Antonov 
; yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto llvm support

External Email Alert

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

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



On 4/20/21 7:00 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
> I noticed similar behavior.
> 
> I am running zeus 3.0.4, "devtool sdk-install llvm" will get llvm 
> 8.0.1.
> 
> When I build meta-clang, and I set TOOLCHAIN?="clang" in local.conf it 
> appears to grab llvm-project-source-9.0.1-9.0.1.
> 

this is intentional, when you use meta-clang, then llvm is preferred from LLVM 
since them we have consistent version of llvm for clang and others.

> *From:*yocto@lists.yoctoproject.org  *On 
> Behalf Of *Anton Antonov
> *Sent:* Tuesday, April 20, 2021 9:51 AM
> *To:* yocto@lists.yoctoproject.org
> *Subject:* Re: [yocto] #yocto llvm support
> 
> *_External Email Alert_*
> 
> *This email has been sent from an account outside of the BAE Systems
> network.*
> 
> Please treat the email with caution, especially if you are requested 
> to click o

Re: [yocto] #yocto llvm support

[Monsees, Steven C (US) via lists.yoctoproject.org]

So, does anyone know proper usage here?

Is this a fully functional llvm drop under ../poky/meta/recipes-devtools ?
Is it compatible with meta-clang?, and can they be used together to build 3rd 
party extensions for my platform ?

Is it better to add supported components this way rather than building them in 
directly to EXT SDK ?

Also, any known issues with meta-clang under zeus 3.0.4 ?

Thanks,
Steve

From: Monsees, Steven C (US)
Sent: Tuesday, April 20, 2021 10:01 AM
To: 'Anton Antonov' ; yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto llvm support


I noticed similar behavior...

I am running zeus 3.0.4, "devtool sdk-install llvm" will get llvm 8.0.1...

When I build meta-clang, and I set TOOLCHAIN?="clang" in local.conf it appears 
to grab llvm-project-source-9.0.1-9.0.1...

From: yocto@lists.yoctoproject.org 
mailto:yocto@lists.yoctoproject.org>> On Behalf 
Of Anton Antonov
Sent: Tuesday, April 20, 2021 9:51 AM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto llvm support

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


Hi Steven,

  I used meta-clang in my recipes and I noticed that:
1. The current release of poky uses LLVM v11.1.0 by default 
(poky/meta/recipes-devtools/llvm/llvm_git.bb)
2. Meta-clang requires LLVM v12.0.0 (meta-clang/conf/layer.conf defines 
LLVMVERSION = "12.0.0")

As a result just including meta-clang into bblayers.conf will require bitbake 
to build a new version of LLVM and rebuild everything which uses it

Anton

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

Re: [yocto] #yocto llvm support

[Monsees, Steven C (US) via lists.yoctoproject.org]

I noticed similar behavior...

I am running zeus 3.0.4, "devtool sdk-install llvm" will get llvm 8.0.1...

When I build meta-clang, and I set TOOLCHAIN?="clang" in local.conf it appears 
to grab llvm-project-source-9.0.1-9.0.1...

From: yocto@lists.yoctoproject.org  On Behalf Of 
Anton Antonov
Sent: Tuesday, April 20, 2021 9:51 AM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto llvm support

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access "Cybersecurity OneSpace Page" and 
report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


Hi Steven,

  I used meta-clang in my recipes and I noticed that:
1. The current release of poky uses LLVM v11.1.0 by default 
(poky/meta/recipes-devtools/llvm/llvm_git.bb)
2. Meta-clang requires LLVM v12.0.0 (meta-clang/conf/layer.conf defines 
LLVMVERSION = "12.0.0")

As a result just including meta-clang into bblayers.conf will require bitbake 
to build a new version of LLVM and rebuild everything which uses it

Anton

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

Re: [yocto] #yocto #sdk SDK_EXTRA_TOOLS inclussion of python-native and devtool

[Monsees, Steven C (US) via lists.yoctoproject.org]

Any one seen this before... ?

SDK appears to be working okay without the inclusion of native python3 
components, not sure how the inclusion breaks devtool...

From: Monsees, Steven C (US)
Sent: Wednesday, April 14, 2021 2:23 PM
To: 'yocto@lists.yoctoproject.org' 
Subject: #yocto #sdk SDK_EXTRA_TOOLS inclussion of python-native and devtool


Working with zeus 3.0.4, extended SDK...

Could someone explain what I overlooked, or why this issue pops up with 
python-native support inclusion ?

Thanks...

When I add in native-python3 support

#
# Additional SDK Setup variables
#

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

SDK_EXTRA_TOOLS = "  \
 nativesdk-python3-pprint \
 nativesdk-python3-pickle \
 nativesdk-python3-shell \
 nativesdk-python3-modules \
 nativesdk-python3-distutils \
 nativesdk-python3-xml \
 nativesdk-python3-compile \
 nativesdk-python3-six \
 nativesdk-cmake \
 "

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

I see the following error with devtool:

13:07 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH
13:08 smonsees@yix490016 /disk0/scratch/smonsees>. 
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux
SDK environment now set up; additionally you may now run devtool to perform 
development tasks.
Run devtool --help for further details.
13:08 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3:
 
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real:
 /opt/limws/3.0.4/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2: bad 
ELF interpreter: No such file or directory
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3:
 line 5: 
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real:
 Success

If I remove the "native-python" components, the issue goes away:

SDK_EXTRA_TOOLS = "  \
nativesdk-cmake \
"

14:09 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH
14:11 smonsees@yix490016 /disk0/scratch/smonsees>. 
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux
SDK environment now set up; additionally you may now run devtool to perform 
development tasks.
Run devtool --help for further details.
14:11 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help
NOTE: Starting bitbake server...
usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]
   [--color COLOR] [-h]
...

OpenEmbedded development tool

options:
  --basepath BASEPATH   Base directory of SDK / build directory
  --bbpath BBPATH   Explicitly specify the BBPATH, rather than getting it
from the metadata
  -d, --debug   Enable debug output
  -q, --quiet   Print only errors
  --color COLOR Colorize output (where COLOR is auto, always, never)
  -h, --helpshow this help message and exit

subcommands:
  Beginning work on a recipe:
add   Add a new recipe
modifyModify the source for an existing recipe
upgrade   Upgrade an existing recipe
  Getting information:
statusShow workspace status
searchSearch available recipes
latest-versionReport the latest version of an existing recipe
check-upgrade-status  Report upgradability for multiple (or all) recipes
  Working on a recipe in the workspace:
build Build a recipe
renameRename a recipe file in the workspace
edit-recipe   Edit a recipe file
find-recipe   Find a recipe file
configure-helpGet help on configure script options
update-recipe Apply changes from external source tree to recipe
reset Remove a recipe from your workspace
finishFinish working on a recipe in your workspace
  Testing changes on target:
deploy-target Deploy recipe output files to live target machine
undeploy-target   Undeploy recipe output files in live target machine
package   Build packages for a recipe
build-image   Build image including workspace recipe packages
runqemu   Run QEMU on the specified image
  Advanced:
build-sdk Build a derivative SDK of this one
extract   Extract the source for an existing recipe
sync  Synchronize the source tree for an existing recipe
exportExport workspace into a tar archive
importImport exported tar archive into workspace
menuconfigAlter build-time configuration for a recipe
  SDK maintenance:
sdk-updateUpdate SDK components
sdk-install   Install additional SDK components
Use devtool  --help to get help on a 

[yocto] #yocto llvm support

[Monsees, Steven C (US) via lists.yoctoproject.org]

Under ../poky/meta/recipes-devtools the is "llvm"...

Devtool search 
Devtool sdk-install 

Will add this component to my EXT SDK...

Is this a fully functional llvm drop ?,
(i.e. is it compatible with meta-clang?, and can I use them together to build 
3rd party extensions for my platform ?)

Is it better to add supported components this way rather than building them in 
directly to EXT SDK ?

Thanks,
Steve

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

[yocto] #yocto #llvm

[Monsees, Steven C (US) via lists.yoctoproject.org]

I attempted to add llvm to my zeus image, and I am seeing the following Yocto 
build error...

What is the actual problem here, and how best resolve ?

Build Configuration:
BB_VERSION   = "1.44.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "rhel-7.9"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "sbcb-default"
DISTRO   = "limws"
DISTRO_VERSION   = "3.0.4"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta
meta-poky= "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
meta-perl
meta-python
meta-filesystems
meta-networking
meta-initramfs
meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-clang   = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel   = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

Initialising tasks: 100% 
|###| Time: 0:00:04
Checking sstate mirror object availability: 100% 
|###| Time: 0:00:00
Sstate summary: Wanted 2129 Found 2090 Missed 39 Current 0 (98% match, 0% 
complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: llvm-8.0.1-r0 do_compile: Execution of 
'/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/temp/run.do_compile.18964'
 failed with exit code 1:
ninja: error: 
'/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/recipe-sysroot-native/usr/bin/llvm-tblgen8.0.1',
 needed by 'include/llvm/IR/Attributes.inc', missing and no known rule to make 
it
WARNING: 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/temp/run.do_compile.18964:1
 exit 1 from 'ninja -v -j 4'

ERROR: Logfile of failure stored in: 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/temp/log.do_compile.18964
Log data follows:
| DEBUG: Executing shell function do_compile
| ninja: error: 
'/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/recipe-sysroot-native/usr/bin/llvm-tblgen8.0.1',
 needed by 'include/llvm/IR/Attributes.inc', missing and no known rule to make 
it
| WARNING: 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/temp/run.do_compile.18964:1
 exit 1 from 'ninja -v -j 4'
| ERROR: Execution of 
'/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/temp/run.do_compile.18964'
 failed with exit code 1:
| ninja: error: 
'/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/recipe-sysroot-native/usr/bin/llvm-tblgen8.0.1',
 needed by 'include/llvm/IR/Attributes.inc', missing and no known rule to make 
it
| WARNING: 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/corei7-64-poky-linux/llvm/8.0.1-r0/temp/run.do_compile.18964:1
 exit 1 from 'ninja -v -j 4'
|
ERROR: Task 
(/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-devtools/llvm/llvm_git.bb:do_compile)
 failed with exit code '1'
NOTE: Tasks Summary: Attempted 5949 tasks of which 5385 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:
  
/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-devtools/llvm/llvm_git.bb:do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
15:16 smonsees@yix490038 
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default>

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

[yocto] #yocto #sdk SDK_EXTRA_TOOLS inclussion of python-native and devtool

[Monsees, Steven C (US) via lists.yoctoproject.org]

Working with zeus 3.0.4, extended SDK...

Could someone explain what I overlooked, or why this issue pops up with 
python-native support inclusion ?

Thanks...

When I add in native-python3 support

#
# Additional SDK Setup variables
#

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

SDK_EXTRA_TOOLS = "  \
 nativesdk-python3-pprint \
 nativesdk-python3-pickle \
 nativesdk-python3-shell \
 nativesdk-python3-modules \
 nativesdk-python3-distutils \
 nativesdk-python3-xml \
 nativesdk-python3-compile \
 nativesdk-python3-six \
 nativesdk-cmake \
 "

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

I see the following error with devtool:

13:07 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH
13:08 smonsees@yix490016 /disk0/scratch/smonsees>. 
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux
SDK environment now set up; additionally you may now run devtool to perform 
development tasks.
Run devtool --help for further details.
13:08 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3:
 
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real:
 /opt/limws/3.0.4/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2: bad 
ELF interpreter: No such file or directory
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3:
 line 5: 
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real:
 Success

If I remove the "native-python" components, the issue goes away:

SDK_EXTRA_TOOLS = "  \
nativesdk-cmake \
"

14:09 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH
14:11 smonsees@yix490016 /disk0/scratch/smonsees>. 
/disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux
SDK environment now set up; additionally you may now run devtool to perform 
development tasks.
Run devtool --help for further details.
14:11 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help
NOTE: Starting bitbake server...
usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]
   [--color COLOR] [-h]
...

OpenEmbedded development tool

options:
  --basepath BASEPATH   Base directory of SDK / build directory
  --bbpath BBPATH   Explicitly specify the BBPATH, rather than getting it
from the metadata
  -d, --debug   Enable debug output
  -q, --quiet   Print only errors
  --color COLOR Colorize output (where COLOR is auto, always, never)
  -h, --helpshow this help message and exit

subcommands:
  Beginning work on a recipe:
add   Add a new recipe
modifyModify the source for an existing recipe
upgrade   Upgrade an existing recipe
  Getting information:
statusShow workspace status
searchSearch available recipes
latest-versionReport the latest version of an existing recipe
check-upgrade-status  Report upgradability for multiple (or all) recipes
  Working on a recipe in the workspace:
build Build a recipe
renameRename a recipe file in the workspace
edit-recipe   Edit a recipe file
find-recipe   Find a recipe file
configure-helpGet help on configure script options
update-recipe Apply changes from external source tree to recipe
reset Remove a recipe from your workspace
finishFinish working on a recipe in your workspace
  Testing changes on target:
deploy-target Deploy recipe output files to live target machine
undeploy-target   Undeploy recipe output files in live target machine
package   Build packages for a recipe
build-image   Build image including workspace recipe packages
runqemu   Run QEMU on the specified image
  Advanced:
build-sdk Build a derivative SDK of this one
extract   Extract the source for an existing recipe
sync  Synchronize the source tree for an existing recipe
exportExport workspace into a tar archive
importImport exported tar archive into workspace
menuconfigAlter build-time configuration for a recipe
  SDK maintenance:
sdk-updateUpdate SDK components
sdk-install   Install additional SDK components
Use devtool  --help to get help on a specific command
14:11 smonsees@yix490016 /disk0/scratch/smonsees>



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53138): https://lists.yoctoproject.org/g/yocto/message/53138
Mute This Topic: https://lists.yoctoproject.org/mt/82099107/21656
Mute 

Re: [yocto] #yocto #sdk -XILINX/vivado dependencies

[Monsees, Steven C (US) via lists.yoctoproject.org]

No the vivado module sets up key variables, the lib path, and the include paths 
for building Xilinx low level drivers built into bootapp/kernel...

I need to be able to include these components in actual SDK build... 

Steve

-Original Message-
From: Khem Raj  
Sent: Tuesday, April 6, 2021 4:28 PM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk -XILINX/vivado dependencies

External Email Alert

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

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


there is KERNEL_MODULE_AUTOLOAD which could be used to load modules on boot, 
don't know if that suffices to what you need but worth looking into.

On Tue, Apr 6, 2021 at 12:47 PM Monsees, Steven C (US) via 
lists.yoctoproject.org  
wrote:
>
>
>
> Working with zeus, aarch64, with Xilinx vivado dependencies…
>
> Kerenl image and bootapp build and run correctly, need to be able to 
> build EXT SDK,,,
>
>
>
> How do I incorporate the dependencies of the low level Xilinx FPGA support  
> (i.e. “vivado”) into the Ext SDK build env ?
>
>
>
> Is there a way to build in support so that the “module load” command would be 
> usable from the “.conf” or  the env-setup script, (i.e. “module load vivado…” 
> ?
>
>
>
> Thanks,
>
> Steve
>
>
>
>
> 
>

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