yocto@lists.yoctoproject.org

Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Khem Raj

#50697

Can you inspect the clang libs for these symbols?

On Wed, Sep 16, 2020 at 7:04 AM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@...> wrote:

Show quoted text

I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references

It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…

Are the following routines accessible/supported under meta-clang ?

libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked

thanks,

Steve

Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)

#50696

Found a cmake issue and fixed almost all of it, down to 1 missing reference:


/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp: In function ‘bool gbe::llvmToGen(gbe::ir::Unit&, const void*, int, bool, int, std::__cxx11::string&)’:
/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:325:68: error: no matching function for call to ‘llvm::LLVMContext::setDiagnosticHandler(void (*)(const llvm::DiagnosticInfo&, void*), gbe::gbeDiagnosticContext*)’
     mod.getContext().setDiagnosticHandler(&gbeDiagnosticHandler,&dc);
                                                                    ^
In file included from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Metadata.h:30:0,
                 from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/TrackingMDRef.h:17,
                 from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/DebugLoc.h:18,
                 from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Instruction.h:22,
                 from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/BasicBlock.h:23,
                 from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_includes.hpp:30,
                 from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:25:
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: candidate: void llvm::LLVMContext::setDiagnosticHandler(std::unique_ptr<llvm::DiagnosticHandler>&&, bool)
   void setDiagnosticHandler(std::unique_ptr<DiagnosticHandler> &&DH,
        ^~~~~~~~~~~~~~~~~~~~
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note:   no known conversion for argument 1 from ‘void (*)(const llvm::DiagnosticInfo&, void*)’ to ‘std::unique_ptr<llvm::DiagnosticHandler>&&’
make[2]: *** [backend/src/CMakeFiles/gbe.dir/llvm/llvm_to_gen.cpp.o] Error 1
make[1]: *** [backend/src/CMakeFiles/gbe.dir/all] Error 2
make: *** [all] Error 2
11:27 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.3/mybuild>

Show quoted text

-----Original Message-----
From: yocto@... [mailto:yocto@...] On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, September 16, 2020 10:05 AM
To: Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

-----Original Message-----
From: Monsees, Steven C (US) 
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references

It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all 
under a standard SDK “rocko based” (2.4.1)…

Are the following routines accessible/supported under meta-clang ?

libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked

thanks,

Steve

Re: [meta-security][PATCH 2/2] apparmor: exclude mips, not supported

Armin Kuster

#50695

On 9/15/20 10:11 PM, Khem Raj wrote:
title says mips but it actually is for mips64 only it seems.right. easy to fix when I commit. Have not built qemumip so its unknown
at this time.

-armin

On Tue, Sep 15, 2020 at 8:12 PM akuster <akuster808@...> wrote:
Signed-off-by: Armin Kuster <akuster808@...>
---
 recipes-mac/AppArmor/apparmor_2.13.4.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index 552cac7..dcdc1f7 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -30,6 +30,8 @@ S = "${WORKDIR}/git"

 PARALLEL_MAKE = ""

+COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
+
 inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative ptest cpan manpages systemd features_check
 REQUIRED_DISTRO_FEATURES = "apparmor"

--
2.17.1

Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)

#50694

I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

Show quoted text

-----Original Message-----
From: Monsees, Steven C (US) 
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references

It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all 
under a standard SDK “rocko based” (2.4.1)…

Are the following routines accessible/supported under meta-clang ?

libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked

thanks,

Steve

Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)

#50693

It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

Show quoted text

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...] 
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all 
under a standard SDK “rocko based” (2.4.1)…

Are the following routines accessible/supported under meta-clang ?

libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked

thanks,

Steve

Re: [meta-security][PATCH 2/2] apparmor: exclude mips, not supported

Khem Raj

#50692

title says mips but it actually is for mips64 only it seems.

Show quoted text

On Tue, Sep 15, 2020 at 8:12 PM akuster <akuster808@...> wrote:

Signed-off-by: Armin Kuster <akuster808@...>
---
 recipes-mac/AppArmor/apparmor_2.13.4.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index 552cac7..dcdc1f7 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -30,6 +30,8 @@ S = "${WORKDIR}/git"

 PARALLEL_MAKE = ""

+COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
+
 inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative ptest cpan manpages systemd features_check
 REQUIRED_DISTRO_FEATURES = "apparmor"

--
2.17.1

[meta-security][PATCH 2/2] apparmor: exclude mips, not supported

Armin Kuster

#50691

Signed-off-by: Armin Kuster <akuster808@...>
---
 recipes-mac/AppArmor/apparmor_2.13.4.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index 552cac7..dcdc1f7 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -30,6 +30,8 @@ S = "${WORKDIR}/git"
 
 PARALLEL_MAKE = ""
 
+COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
+
 inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative ptest cpan manpages systemd features_check
 REQUIRED_DISTRO_FEATURES = "apparmor"
 
-- 
2.17.1

[meta-security][PATCH 1/2] packagegroup-core-security: add more pkgs to base group

Armin Kuster

#50690

Signed-off-by: Armin Kuster <akuster808@...>
---
 .../packagegroup/packagegroup-core-security.bb  | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 6aa0d6c..1d01800 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -9,6 +9,8 @@ PACKAGES = "\
     packagegroup-core-security \
     packagegroup-security-utils \
     packagegroup-security-scanners \
+    packagegroup-security-audit \
+    packagegroup-security-hardening \
     packagegroup-security-ids  \
     packagegroup-security-mac  \
     "
@@ -16,6 +18,8 @@ PACKAGES = "\
 RDEPENDS_packagegroup-core-security = "\
     packagegroup-security-utils \
     packagegroup-security-scanners \
+    packagegroup-security-audit \
+    packagegroup-security-hardening \
     packagegroup-security-ids  \
     packagegroup-security-mac  \
     "
@@ -23,18 +27,23 @@ RDEPENDS_packagegroup-core-security = "\
 SUMMARY_packagegroup-security-utils = "Security utilities"
 RDEPENDS_packagegroup-security-utils = "\
     checksec \
+    ding-libs \
+    ecryptfs-utils \
+    fscryptctl \
+    keyutils \
     nmap \
     pinentry \
+    python3-privacyidea \
+    python3-fail2ban \
     python3-scapy \
-    ding-libs \
-    keyutils \
     ${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " libseccomp",d)} \
-    ${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd", "",d)} \
-    ${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils", "",d)} \
+    ${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd google-authenticator-libpam", "",d)} \
+    ${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils packctl", "",d)} \
     "
 
 SUMMARY_packagegroup-security-scanners = "Security scanners"
 RDEPENDS_packagegroup-security-scanners = "\
+    isic \
     nikto \
     checksecurity \
     ${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 riscv64", "", " clamav clamav-freshclam clamav-cvd",d)} \
-- 
2.17.1

Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Khem Raj

#50689

On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@...> wrote:

I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all under a standard SDK “rocko based” (2.4.1)…

Are the following routines accessible/supported under meta-clang ?

libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that
its not emitting bunch of libraries which needs to then individually
linked

thanks,

Steve

#yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)

#50688

I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all under a standard SDK “rocko based” (2.4.1)…

Are the following routines accessible/supported under meta-clang ?

libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'

thanks,

Steve

[auh][PATCH] buildhistory: do not error on version-going-backwards

Alexander Kanavin

#50687

In some situation this may happen in initial builds and
should not be treated as an error.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
 modules/buildhistory.py | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/modules/buildhistory.py b/modules/buildhistory.py
index edf9ae6..6649023 100644
--- a/modules/buildhistory.py
+++ b/modules/buildhistory.py
@@ -40,7 +40,16 @@ class BuildHistory(object):
 
     def init(self, machines):
         for machine in machines:
-            self.bb.complete(self.pn, machine)
+            try:
+                self.bb.complete(self.pn, machine)
+            except Error as e:
+                for line in e.stdout.split("\n"):
+                    # version going backwards is not a real error
+                    if re.match(".* went backwards which would break package feeds .*", line):
+                        break
+                else:
+                    raise e
+
 
     def diff(self):
         try:
-- 
2.28.0

[auh][PATCH] buildhistory: simplify the handling of

Alexander Kanavin

#50686

The module was doing a lot of things, none of which are necessary:
- setting up a separate buildhistory repo for each recipe
- running cleansstate before doing initial build
- messing about with buildhisory revisions

Instead just run buildhistory-diff on the defaults right
after building the first target. This should also address
the various buildhistory problems seen on the AB.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
 modules/buildhistory.py | 25 ++-----------------------
 modules/steps.py        | 13 +++----------
 2 files changed, 5 insertions(+), 33 deletions(-)

diff --git a/modules/buildhistory.py b/modules/buildhistory.py
index 4fdc36c..edf9ae6 100644
--- a/modules/buildhistory.py
+++ b/modules/buildhistory.py
@@ -37,42 +37,21 @@ class BuildHistory(object):
         self.bb = bb
         self.pn = pn
         self.workdir = workdir
-        self.revs = []
-
-        self.buildhistory_dir = os.path.join(self.workdir, 'buildhistory')
-        if not os.path.exists(self.buildhistory_dir):
-            os.mkdir(self.buildhistory_dir)
-
-        self.git = Git(self.buildhistory_dir)
-
-        os.environ['BB_ENV_EXTRAWHITE'] = os.environ['BB_ENV_EXTRAWHITE'] + \
-                                    " BUILDHISTORY_DIR"
-        os.environ["BUILDHISTORY_DIR"] = self.buildhistory_dir
 
     def init(self, machines):
-        self.bb.cleansstate(self.pn)
         for machine in machines:
             self.bb.complete(self.pn, machine)
-            self.revs.append(self.git.last_commit("master"))
-
-    def add(self):
-        self.revs.append(self.git.last_commit("master"))
 
     def diff(self):
-        rev_initial = self.revs[0]
-        rev_final = self.revs[-1]
-
         try:
-            cmd = "buildhistory-diff -p %s %s %s"  % (self.buildhistory_dir, 
-                rev_initial, rev_final)
+            cmd = "buildhistory-diff"
             stdout, stderr = bb.process.run(cmd)
             if stdout and os.path.exists(self.workdir):
                 with open(os.path.join(self.workdir, "buildhistory-diff.txt"),
                         "w+") as log:
                     log.write(stdout)
 
-            cmd_full = "buildhistory-diff -a -p %s %s %s"  % (self.buildhistory_dir, 
-                        rev_initial, rev_final)
+            cmd_full = "buildhistory-diff -a"
             stdout, stderr = bb.process.run(cmd_full)
             if stdout and os.path.exists(self.workdir):
                 with open(os.path.join(self.workdir, "buildhistory-diff-full.txt"),
diff --git a/modules/steps.py b/modules/steps.py
index 46d49fe..811b88d 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -126,15 +126,9 @@ def compile(devtool, bb, git, opts, pkg_ctx):
     for machine in opts['machines']:
         I(" %s: compiling upgraded version for %s ..." % (pkg_ctx['PN'], machine))
         _compile(bb, pkg_ctx['PN'], machine, pkg_ctx['workdir'])
-        if opts['buildhistory']:
-            pkg_ctx['buildhistory'].add()
-
-def buildhistory_diff(devtool, bb, git, opts, pkg_ctx):
-    if not opts['buildhistory']:
-        return
-
-    I(" %s: Checking buildhistory ..." % pkg_ctx['PN'])
-    pkg_ctx['buildhistory'].diff()
+        if opts['buildhistory'] and machine == opts['machines'][0]:
+            I(" %s: Checking buildhistory ..." % pkg_ctx['PN'])
+            pkg_ctx['buildhistory'].diff()
 
 def _rm_source_tree(devtool_output):
     for line in devtool_output.split("\n"):
@@ -161,5 +155,4 @@ upgrade_steps = [
     (devtool_upgrade, "Running 'devtool upgrade' ..."),
     (devtool_finish, "Running 'devtool finish' ..."),
     (compile, None),
-    (buildhistory_diff, None),
 ]
-- 
2.28.0

Yocto Technical Team Minutes, Engineering Sync, for September 15, 2020

Trevor Woerner

#50685

Yocto Technical Team Minutes, Engineering Sync, for September 15, 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, David Reyna, Saul Wold, Richard Purdie, Tim Orling,
Randy MacLeod, Joshua Watt, Jan-Simon Möller, Michael Halstead, Paul
Barker, Mark Morton, Steve Sakoman, Bruce Ashfield, Trevor Gamblin, Mark
Asselstine, Stacy Gaikovaia

== notes ==
- closed m3, hasn’t built yet (in freeze) waiting for docs
- good progress on the docs, past point-of-no-return
- there appear to be 3 AB issues:
    - qemu-mips issue
        - limited to 256MB of memory, systemd needs more
        - Armin tried raising it, but caused other issues (will revert)
    - weird networking dropout issue when qemu testing
        - was it caused by something in the image?
        - or caused by qemu, kernel, etc?
        - need to detect this issue and report on if anything else is dead
        - seen on x86, arm and mips
        - intermittent
    - occasional bitbake timeout
        - bitbake says it can’t connect to the server
        - due to sync thread in bitbake, 90 second+ disk stalls (apparently)
          while writing logs, there’s a 60[s] timeout limit
        - devtool doesn’t do re-nice’ing, might be related
- parsing issue seems to be solved (thanks for help from jpew)

== general ==

Randy: bitbake timeout is to add nice to devtool or to not block?
RP: thread is there to allow cache to be written out while allowing bitbake
    to do other things, we could just increase timeout on UI, or have bitbake
    write the cache directly
JPEW: it’s during client shutdown?
RP: yes, when a given client is done using bitbake, the sync should already be
    happening at that time, we need to make sure the sync is done, if not it
    will wait on sync completion
RP: it’s a high bug for m3, but will probably push to m4, won’t hold up m3

RP: lots of unassigned bugs in 3.2 if anyone has time

Randy: you listed off a bunch of AB issues, have we seen any improvements
RP: yes, there have been cleanups in various areas that help expose these
    issues
Randy: is it an issue of overloading?
RP: i think this is a consequence of heavy automated testing. sure we could
    half the number of workers or increase timeouts. or maybe we have bitbake
    act differently on the AB than the way it would normally. we could
    implement some pinging infrastructure so the UI can know that bitbake
    hasn’t died
Timo: is this an NFS issue, or just a general I/O issue
RP: don’t have enough data to say, but feels like an I/O issue
Timo: how will devtool do io-nice?
RP: tinfoil execution
RP: appears to happen when bitbake is extracting kernel source, devtool is
    probably using external source, so we’ll probably need to wrap the
    extraction of the source code with io-nice

JPEW: i’m still working on multiprocessing things (still multiprocessing,
    but not using the python multiprocessing module), maybe not for m4, but do
    we still want to keep looking at?
RP: i’d like to look at the code before deciding
JPEW: i’ll clean it up some more

Randy: rust, people looking to get it into 3.3, i need to push the patches
    somewhere, would be happy to have help.
RP: i think AlexK is interested. keep him in the loop (he has a great track
    record with gnarly problems)

PaulB: doing research for my talk next week at Linaro Connect for license
    compliance. wrt rust, whether it can use build offline etc. will be
    looking at dunfell and master and try to find answers in the next week or
    so
Randy: sounds good, there’s currently no major differences between what
    i’m working on and what’s in meta-rust
PaulB: we need to be able to generate source tarballs, handle being behind
    corporate firewalls, offline builds. i want to investigate this wrt rust,
    golang, and nodejs
RP: it’d be great if this were done as a set of automated tests that could
    be added to the project
PaulB: don’t know that all the test code is available, some of the builds
    would be big, but can look into it

PaulB: also want to mention outreachy that Paul has worked on and mention it
    in my talk

RP: wrt people interested in rust. maybe try Yann or Leon

David: call for papers for YP Summit is open
Randy: 6 days until deadline?
David: yes
Randy: next Monday
Timo: Christopher Clarke and I will be doing virtualization (rehashed and
    expanded)

Randy: i’d like to introduce Stacy, working at WR as a co-op for this term
RP: and there’s already a patch in
Stacy: and hopefully another and another!
(various): welcome! ☺

Yocto Project Status WW37'20

Stephen Jolley

#50684

Current Dev Position: YP 3.2 M3

Next Deadline: YP 3.2 M3 Feature Freeze - Now

Next Team Meetings:

Bug Triage meeting Thursday Sept. 17th at 7:30am PDT (https://zoom.us/j/454367603)
Monthly Project Meeting Tuesday Oct. 6th at 8am PDT (https://zoom.us/j/990892712)
Weekly Engineering Sync Tuesday Sept. 15th at 8am PDT (https://zoom.us/j/990892712)
Twitch - See https://www.twitch.tv/theyoctojester

Key Status/Updates:

M3 has now closed and we’re at feature freeze for 3.2.
We continue to be in holding pattern for M3 whilst we sort out the sphinx documentation migration. We’re at a point where we just need to press on and complete it.
There are three significant autobuilder issues being faced currently:

qemumips fails with systemd with 256MB memory, it needs 512MB. If we enable 512MB, we see random hangs. Unless someone can debug and sort the qemu memory issues, we may end up disabling core-image-sato-sdk and core-image-full-cmdline for qemumips+systemd
networking with qemu images appears to glitch at times (particularly slower targets such as ltp and qemumips), the session stalls with “no route to host”. We need better serial interrogation to determine the state of qemu when this happens, its unclear if qemu/kernel hangs, networking fails or what is breaking.
The timeouts in bitbake have been narrowed down to the “SyncThread” which writes out the cache data to disk stalling for around 90s. We don’t have a plan to address this right now but its at least process in identifying the cause

The bitbake parsing hangs should hopefully all be resolved now, thanks to Joshua for help there.
A preview of the sphinx built documentation is available at https://docs.yoctoproject.org/, work is ongoing to complete the migration work and blocking M3.
We continue to struggle with a number of autobuilder intermittent bugs. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

One way to help the project is to help us with bugs that are currently unassigned but ideally needed during YP 3.2. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs

YP 3.2 Milestone Dates:

YP 3.2 M3 build date 2020/8/31
YP 3.2 M3 Release date 2020/9/11
YP 3.2 M4 build date 2020/10/5
YP 3.2 M4 Release date 2020/10/30

Planned upcoming dot releases:

YP 3.1.3 build date 2020/9/14
YP 3.1.3 release date 2020/9/25

Tracking Metrics:

WDD 2466 (last week 2461) (https://wiki.yoctoproject.org/charts/combo.html)
Poky Patch Metrics

Total patches found: 1258 (last week 1254)
Patches in the Pending State: 496 (39%) [last week 496 (40%)]

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Re: Ethernet device with systemd-networkd on Yocto won't work (rejects ARP replies), but does work with /etc/network/interfaces #yocto #systemd

eliranl@...

#50683

Thanks Matt!! This solved it.

And yes, the branch is thud-l4t-r32.3.1.

WIC cp is not copying files to ext4 partition #yocto

mail2uvijay@...

#50682

Hi Team, Able to create image for using Yocto. After creating the image, I am trying to copy one file using 'wic cp' to 'extt4' partition. while copying i am not getting any error, after flashing the image on board copied file was not present. Is there any other ways to copy a file to ext4 partition. Where as in case vfat partition i could able to copy the file successfully. Regards, Vijay

M+ & H bugs with Milestone Movements WW37

Stephen Jolley

#50681

All,

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

Priority	Bug ID	Short Description	Changer	Owner	Was	Became
High	13646	runtime tests sometimes can't login to the serial console on systemd images (generates warning)	randy.macleod@...	kai.kang@...	3.2 M3	3.2 M4
	14039	bitbake selftest failing with freedesktoporg git	randy.macleod@...	richard.purdie@...	3.2 M3	3.2 M4

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Enhancements/Bugs closed WW37!

Stephen Jolley

#50680

All,

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

Who	Count
ross@...	2
ydirson@...	2
nickersk@...	1
Grand Total	5

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Current Autobuilder Intermittent bugs by the WW created or closed.

Stephen Jolley

#50679

All,

Below are the lists of open and closed medium or higher Autobuilder Intermittent bugs by the WW created or closed'.

Opened	Count	Closed	Count
2019WW47	1	2020WW26	2
2020WW8	1	2020WW27	2
2020WW24	1	2020WW28	3
2020WW25	1	2020WW29	2
2020WW29	1	2020WW30	3
2020WW30	1	2020WW31	1
2020WW31	2	2020WW33	1
2020WW33	5	2020WW34	4
2020WW34	2	2020WW35	1
2020WW35	3	2020WW37	2
2020WW36	3	Grand Total	21
2020WW37	1
Grand Total	22

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Current high bug count owners for Yocto Project 3.2

Stephen Jolley

#50678

All,

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

Who	Count
richard.purdie@...	32
david.reyna@...	22
akuster808@...	18
bluelightning@...	17
bruce.ashfield@...	17
ross@...	11
mark.morton@...	11
kai.kang@...	10
JPEWhacker@...	9
Qi.Chen@...	9
timothy.t.orling@...	9
trevor.gamblin@...	7
sakib.sajal@...	6
randy.macleod@...	5
raj.khem@...	5
hongxu.jia@...	5
mostthingsweb@...	4
rpjday@...	4
mingli.yu@...	4
yi.zhao@...	3
jon.mason@...	3
kergoth@...	2
michael@...	2
steve@...	2
akuster@...	2
alejandro@...	2
jaewon@...	2
jpuhlman@...	2
chee.yang.lee@...	2
jeanmarie.lemetayer@...	2
ydirson@...	2
mark.hatle@...	2
anuj.mittal@...	1
khairul.rohaizzat.jamaluddin@...	1
liezhi.yang@...	1
joe.slater@...	1
changqing.li@...	1
maxime.roussinbelanger@...	1
aehs29@...	1
ankur.tyagi85@...	1
matt.ranostay@...	1
dl9pf@...	1
amber.n.elliot@...	1
liu.ming50@...	1
kai.ruhnau@...	1
jason.wessel@...	1
Grand Total	247

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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