|
Re: Improving NPM recipe build speed
|
|
|
Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase
On Fri, 2021-05-07 at 10:10 +0300, Thomas Hill via lists.yoctoproject.org wrote: On Thu, 6 May 2021, 13:44 Martin Jansa <Martin.Jansa@...> wrote:
On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org <tom.hill=inbox.lv@...> wrote:
Hi Martin! On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?
No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001. Ok. Thanks. I can confirm that the change of the bitbake users UID to 1111
did not solve the issue.
I will open a new thread because I don't see why this fails. I use oe_runmake
in my do_install function and got the impression that oe_runmake should take
care of this via fakeroot. When you install files during do_install, you need to be clear about who you want to own the end result. If you do something like "touch ${D}/x", the it will be owned by the default user which in a fakeroot context under pseudo is root. If however you cp a file to ${D}/x, it would depend what you told cp to do about ownership. If the original file was owned by user 1001, it may try and preserve that. We don't know what your code is doing in do_install but its almost certainly not setting the file ownership correctly. Cheers, Richard
|
|
|
[meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot
From: Andrei Gherzan <andrei.gherzan@...> The runqemu script depends on having the native sysroot populated for the qemu recipes. Add the required dependency to the mix. Signed-off-by: Andrei Gherzan <andrei.gherzan@...> --- classes/zephyr-qemuboot.bbclass | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass index 5ac1c86..f508b45 100644 --- a/classes/zephyr-qemuboot.bbclass +++ b/classes/zephyr-qemuboot.bbclass @@ -35,3 +35,22 @@ python do_bootconf_write() { } addtask do_bootconf_write before do_build after do_deploy + +# The runqemu script requires the native sysroot populated for the qemu +# recipes. Usually, this is pulled in by a do_image dependency (see +# baremetal-helloworld_git, for example), but in this case, there is no such +# task, so we hook in the dependency to do_bootconf_write. This also ensures +# that builds from sstate will also have this requirement satisfied. +python () { + # do_addto_recipe_sysroot doesnt exist for all recipes, but we need it to have + # /usr/bin on recipe-sysroot (qemu) populated + def extraimage_getdepends(task): + deps = "" + for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split(): + # Make sure we only add it for qemu + if 'qemu' in dep: + deps += " %s:%s" % (dep, task) + return deps + d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot')) + d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_populate_sysroot')) +} -- 2.31.1
|
|
|
Path ./package/usr/lib/libcryptopp.so.8 is owned by uid 1111, gid 1111, which doesn't match any user/group on target. This may be due to host contamination.
Hi!
I try to create a libcryptopp package for my yocto build with the appended bb-recipe.
That worked without problems on my old build server with Yocto 3.0.
Now I have moved to a new build server and upgrade to Yocto 3.3. Now I have the problem that the do_package function failed.
,---[ bitbake core-image-minimal ]---
| WARNING: libcryptopp-8.2.0+gitAUTOINC+9dcc26c582-r8 do_package: KeyError in ./package/usr/lib/libcryptopp.so.8
| ERROR: libcryptopp-8.2.0+gitAUTOINC+9dcc26c582-r8 do_package: Error executing a python function in exec_python_func() autogenerated:
| [...]
| Exception: Exception: KeyError: 'getpwuid(): uid not found: 1001'
| Path ./package/usr/lib/libcryptopp.so.8 is owned by uid 1001, gid 1001, which doesn't match any user/group on target. This may be due to host contamination.
| [...]
| ERROR: Task (/home/thomas/yocto/meta-X2/recipes-X2/libcryptopp/libcryptopp_8.2.0.bb:do_package) failed with exit code '1'
`------------------
I checked the list and found similar problems but not a real solution for me.
libcryptopp's Makefile uses "cp" for installation. I understand this is bad so I patched the Makefile to use "install" instead. That is the recommended usage I could read in the yocto manual. But this does not help either.
As I understand will the do_install and oe_runmake using the bitbake user's UID for installation in a temp dir. Afterwards the do_package uses fakeroot to create the package with root:root file ownership in the package. Right?
In this case I don't understand where the problem is.
I do not run bitbake as root - why should I? So I don't see a possibility to change the files in the temp dir with "chmod" or "install -o 0".
My current bitbake user has UID 1001. On the old server I think it was 1000. Can this be a problem? I tried a new user with UID 1111 but got the same error. Unfortunatelly I can't test with user 1000. It is occupied.
I am out of ideas. Can someone please poke me in the right direction?
Thanks a lot!
Tom
|
|
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.2.4.rc1)
Hi all,
Intel and WR YP QA is planning for QA execution for YP build yocto-3.2.4.rc1. We are planning to execute following tests for this cycle:
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone
ETA for completion is next Wednesday, 12 May
Thanks,
Sangeeta
toggle quoted messageShow quoted text
-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Friday, 7 May, 2021 12:06 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.2.4.rc1)
A build flagged for QA (yocto-3.2.4.rc1) was completed on the autobuilder and is
available at:
https://autobuilder.yocto.io/pub/releases/yocto-3.2.4.rc1
Build hash information:
bitbake: e05d79a6ed92c9ce17b90fd5fb6186898a7b3bf8
meta-arm: 39bc4076b2d9a662111beaa0621ee9c1e37f56ea
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: c325d3e2eab9952dc175a38f31b78fecdcdd0fcc
meta-kernel: 4b288396eff43fe9b1a233aed1ce9b48329a2eb6
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: d47b7cdc3508343349f3bb3eacb2dc3227dd94d2
poky: 60c8482769f38a4db6f38d525405c887794511a9
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...
|
|
|
Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase
On Thu, 6 May 2021, 13:44 Martin Jansa <Martin.Jansa@...> wrote: On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org <tom.hill=inbox.lv@...> wrote:
Hi Martin! On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?
No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001. Ok. Thanks. I can confirm that the change of the bitbake users UID to 1111 did not solve the issue. I will open a new thread because I don't see why this fails. I use oe_runmake in my do_install function and got the impression that oe_runmake should take care of this via fakeroot. Tom
|
|
|
QA notification for completed autobuilder build (yocto-3.2.4.rc1)
Pokybuild User <pokybuild@...>
A build flagged for QA (yocto-3.2.4.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.2.4.rc1Build hash information: bitbake: e05d79a6ed92c9ce17b90fd5fb6186898a7b3bf8 meta-arm: 39bc4076b2d9a662111beaa0621ee9c1e37f56ea meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43 meta-intel: c325d3e2eab9952dc175a38f31b78fecdcdd0fcc meta-kernel: 4b288396eff43fe9b1a233aed1ce9b48329a2eb6 meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879 oecore: d47b7cdc3508343349f3bb3eacb2dc3227dd94d2 poky: 60c8482769f38a4db6f38d525405c887794511a9 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.purdie@...
|
|
|
Re: #yocto cmake configurations
#yocto
Thanks… I forgot that… linked.
I appreciate the help.
Steve
toggle quoted messageShow quoted text
From: Khem Raj <raj.khem@...>
Sent: Wednesday, May 5, 2021 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
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.
|
usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missing
or present after the faulting .a in linker cmd
I made some modification in the cmake modules to adjust for the linker issue below, but now I appear
to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)…
The link command is attached as “tmp.txt”.
There are a lot of these being generated, this is but a subset…
Note:
(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?
(2) the code with the undefined reference does appear to be missing the proper header
file reference
/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 `CodeGenModule':
/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:114:
undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) 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:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) 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:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) 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 `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543:
undefined 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::checkAliases()':
/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:304:
undefined reference to `clang::Decl::getDefiningAttr() 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::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539:
undefined 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 `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543:
undefined 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<void (clang::FunctionDecl*)>) 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'
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
|
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 <raj.khem@...>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
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 ?
Yes, LLVM & Clang…
From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
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 ?
Attached…
From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
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 ?
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@... <yocto@...>
On Behalf Of Monsees, Steven C (US) via
lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@...
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
|
|
|
Next Yocto Project LTS - April 2022
I'm pleased to be able to announce that the project is planning to have
the April 2022 release next year be our next LTS release.
This fits in with our original announced plan of 2 year cycles and
recognises that the LTS has been well received by members and our
community. It also aligns well with LTS releases of other projects
meaning we have "co-travellers".
The current dunfell LTS would be due to end at that time. There has
been discussion about extending it beyond the currently planned
timeframe but no agreement/decision has been made on the extra finance
that would require at this time. There is also some concern about the
potential pressure on layer maintainers in wider ecosystem which we
plan to investigate further.
By confirming this now, we're hoping to give people a chance to align
strategies and plan for feature development to land into the LTS. There
is a clear need for any new/experimental changes to be planned/developed
now in order to ensure they're ready and stabilised for the LTS.
Cheers,
Richard
|
|
|
[PATCH] config.json: Remove -j option for reproducibility as live output is useful
The -j option has the side effect that the output is cached. For a long running
single threaded target, the live output is more useful so switch to it.
Signed-off-by: Richard Purdie <richard.purdie@...>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index 3e12d3f..6533dab 100644
--- a/config.json
+++ b/config.json
@@ -191,7 +191,7 @@
"SDKMACHINE" : "x86_64",
"step1" : {
"shortname" : "Reproducible Selftest",
- "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1 oe-selftest -r reproducible -j 1"],
+ "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1 oe-selftest -r reproducible"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
}
--
2.30.2
|
|
|
Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase
Hi Martin!
On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?
No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001.
|
|
|
Re: Hardknott - pseudo excluded from intercept_scripts
On Wed, 2021-05-05 at 00:56 -0700, Chuck Wolber wrote: The following code is an effective workaround. It must be added after the core-image is inherited.
python () {
pseudo_ignore_paths = d.getVar('PSEUDO_IGNORE_PATHS')
result = ','.join([x for x in pseudo_ignore_paths.split(',') if "intercept_scripts" not in x])
d.setVar('PSEUDO_IGNORE_PATHS', result)
}
..Ch:W..
On Tue, May 4, 2021 at 8:53 PM Chuck Wolber via lists.yoctoproject.org <
chuckwolber=gmail.com@...> wrote:
I was attempting an image build with Yocto Hardknott, and I ran into a chown problem during do_rootfs(). I
traced it down to ${WORKDIR}/intercept_scripts showing up in the PSEUDO_IGNORE_PATHS environment variable.
This commit made the change:
https://git.openembedded.org/openembedded-core/commit/meta/classes/image.bbclass?id=9463be2292b942a1072eea88881b9644e55aadb9
I continued down the rabbit hole until I got here:
https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n173
Line 192 specifically is the smoking gun. The files are being copied from poky/scripts/postinst-intercepts
into the ${WORKDIR}/intercept_scripts directory and immediately failing when the copyFile utility attempts
to do a chown.
Is there any logical explanation for this? Is this a bug or am I doing something wrong? Is there a
workaround?
This should be fixed in master, the issue was triggered by a checkout owned by root/root: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=eff192abe2ee43ebf981bafbb7fca8602ebdcf0cSteve/Anuj: We'll likely want to backport that one. Cheers, Richard
|
|
|
Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase
Hi Martin! On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running? Thanks! Tom
|
|
|
Re: SSH_AUTH_SOCK unavailable when pulling modules
#golang
Adding BB_ORIGENV to do_compile[vardepsexclude] solved the issue. Thanks for your help!
|
|
|
Re: SSH_AUTH_SOCK unavailable when pulling modules
#golang
Hi Richard,
Unfortunately, that doesn't make the error messages go away. I agree that it's not great that go-mod fetches during do_compile but that's the way it currently is.
For completeness sake, here is the complete minimal example that _does_ compile. However, error messages à la
ERROR: When reparsing [...]/golang-test/golang-test.bb:do_compile, the basehash value changed from be5e3ca0e52fd3e3a0315fb32a2845f097bb6925940a8141b6f4d99fa2423e20 to fc952756231a898ae7d3fd611607066b349042f5313b8363d11eef18ed317ed2. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake golang-test -cdo_compile -Snone
ERROR: Then:
ERROR: $ bitbake golang-test -cdo_compile -Sprintdiff
are spewed out. Here's the recipe:
LICENSE = "CLOSED"
GO_IMPORT = "bitbucket.org/sven_schwermer/golang-a"
SRC_URI = "git://git@${GO_IMPORT};protocol=ssh;branch=master"
SRCREV = "f7d820d09a5b2332737a8105b3efd9c1e8e51d32"
inherit go-mod
do_compile() {
export SSH_AUTH_SOCK="${@d.getVar('BB_ORIGENV', False).getVar('SSH_AUTH_SOCK', False)}"
go_do_compile
}
bitbucket.org/sven_schwermer/golang-a pulls in a secondary dependency (bitbucket.org/sven_schwermer/golang-b) which is not publicly available. This is golang-a's go.mod:
module bitbucket.org/sven_schwermer/golang-a
go 1.16
require bitbucket.org/sven_schwermer/golang-b v0.0.0-20210505180831-90ba3cd6391e
I have tested this also on latest poky@master (5a0679cb75) with identical results.
|
|
|
Khem Raj
On Wed, May 5, 2021 at 7:13 PM Bruce Ashfield <bruce.ashfield@...> wrote:
On Wed, May 5, 2021 at 8:42 PM Chuck Wolber <chuckwolber@...> wrote:
I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.
I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:
FOO += "item1"
FOO += "item2"
Whereas this pattern gives us the "what", but not the "why":
FOO = "item1 \
item2 \
"
After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
The other issue with large formatting patches, is that they make a
history "wall". So when we are debugging and trying to figure why a
change was made, you always have to jump over the wall (or dig under
it) to get the real information.
right, that's what if we want to do this then it has to be persisted with otherwise it will end up being one time exercise with all these losses you described. As such, I'm not a fan of changes like this, unless they are coupled
to some sort of functional change. So I'd be hesitant to take them
into recipes that I end up holding the bag when things break.
Cheers,
Bruce
So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?
..Ch:W..
--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
|
|
|
On Wed, May 5, 2021 at 8:42 PM Chuck Wolber <chuckwolber@...> wrote:
I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.
I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:
FOO += "item1"
FOO += "item2"
Whereas this pattern gives us the "what", but not the "why":
FOO = "item1 \
item2 \
"
After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
The other issue with large formatting patches, is that they make a history "wall". So when we are debugging and trying to figure why a change was made, you always have to jump over the wall (or dig under it) to get the real information. As such, I'm not a fan of changes like this, unless they are coupled to some sort of functional change. So I'd be hesitant to take them into recipes that I end up holding the bag when things break. Cheers, Bruce
So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?
..Ch:W..
--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
Khem Raj
On 5/5/21 5:41 PM, Chuck Wolber wrote: I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.
I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:
FOO += "item1"
FOO += "item2"
Whereas this pattern gives us the "what", but not the "why":
FOO = "item1 \
item2 \
"
After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that? I think it is a good idea, however, to make it persistent it would be nice to have a linter, which can do such checks and perhaps we can enable this in autobuilders so we can keep such cleansups maintained ..Ch:W..
--
*"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire*
|
|
|
Chuck Wolber
I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.
I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:
FOO += "item1" FOO += "item2"
Whereas this pattern gives us the "what", but not the "why":
FOO = "item1 \ item2 \ "
After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?
..Ch:W..
-- "Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire
|
|
|
Re: #yocto cmake configurations
#yocto
Khem Raj
usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missing or present after the faulting .a in linker cmd
I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which
meta-clang generated under the SDK… (see below)…
The link command is attached as “tmp.txt”.
There are a lot of these being generated, this is but a subset…
Note:
(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of
this are, no ?
(2) the code with the undefined reference does appear to be missing the proper header file reference
/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 `CodeGenModule':
/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:114:
undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) 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:116:
undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) 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:118:
undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) 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 `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined
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::checkAliases()':
/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:304: undefined
reference to `clang::Decl::getDefiningAttr() 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::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined
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 `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':
/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined
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<void (clang::FunctionDecl*)>) 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'
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
|
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 <raj.khem@...>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
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 ?
Yes, LLVM & Clang…
From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
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 ?
Attached…
From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
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 ?
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@... <yocto@...>
On Behalf Of Monsees, Steven C (US) via
lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@...
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
|
|
|
