Date   

Re: How to completely uninstall a pre-installed package in Yocto #linux #yocto

Josef Holzmayr
 

Howdy!

Am Mi., 15. Juli 2020 um 07:40 Uhr schrieb Soi, Sheng Leong
<sheng.leong.soi@...>:

The question is how to completely uninstall the pre-installed package in Yocto. Thanks

I found out that one of the packages in Yocto is unwanted, and wish to completely uninstall the package.
In contrast to a general purpose distribution where you have little
control over the default set, there is no need to install anything you
do not want. So the correct solution is: do not install that package.

Even moreso, removing it later might be impossible if the image
doesn't have package management enabled.

Greetz


Re: [meta-selinux][PATCH 0/4] refpolicy: update to 20200229+git

Yi Zhao
 

On 7/15/20 12:19 AM, Scott Murray wrote:
On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
If we still keep two versions of refpolicy, it is difficult to maintain two huge local patchsets. So drop this version and only keep the git version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1 enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.
[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd. That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration. My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"

Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"


If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.


//Yi


PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-targeted"

Any ideas?

Thanks,

Scott


How to completely uninstall a pre-installed package in Yocto #linux #yocto

Soi, Sheng Leong
 

Hi,

I found out that one of the packages in Yocto is unwanted, and wish to completely uninstall the package.

 


The question is how to completely uninstall the pre-installed package in Yocto. Thanks

FYI, I am new in building and compiling Yocto image.

 

 


Re: [meta-security][PATCH] ccs-tools:Fix build error when enable multilib.

Armin Kuster
 



On 7/6/20 10:30 PM, zhengruoqin wrote:
ERROR: lib32-ccs-tools-1.8.4-r0 do_install: oe_runmake failed
ERROR: lib32-ccs-tools-1.8.4-r0 do_install: Execution of
'/build-armv8/tmp/work/armv7ahf-neon-mllib32-linux-gnueabi/lib32-ccs-tools/1.8.4-r0/temp/run.do_install.22368'
failed with exit code 1:
make: *** No rule to make target 'install'.  Stop.
WARNING: exit code 1 from a shell command.

Signed-off-by: Zheng Ruoqin <zhengrq.fnst@...>
---
 recipes-mac/ccs-tools/ccs-tools_1.8.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
merged.
Thanks

diff --git a/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb b/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
index 2e37c0b..79af6a5 100644
--- a/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
+++ b/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
@@ -13,7 +13,7 @@ SRC_URI = "http://osdn.dl.sourceforge.jp/tomoyo/49693/${BPN}-${PV}-${DS}.tar.gz"
 SRC_URI[md5sum] = "eeee8eb96a7680bfa9c8f6de55502c44"
 SRC_URI[sha256sum] = "c358b80a2ea77a9dda79dc2a056dae3acaf3a72fcb8481cfb1cd1f16746324b4"
 
-S = "${WORKDIR}/${PN}"
+S = "${WORKDIR}/${BPN}"
 
 inherit features_check
 


    


Re: [meta-security][PATCH] bastille: Deleted redundant inherit to fix error when enable multilib.

Armin Kuster
 

merged

On 7/10/20 12:04 AM, zhengruoqin wrote:
There is no need to inherit module-base. Because this inherit will stop
bastille to build to lib32-bastille.

Signed-off-by: Zheng Ruoqin <zhengrq.fnst@...>
---
 recipes-security/bastille/bastille_3.2.1.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/recipes-security/bastille/bastille_3.2.1.bb b/recipes-security/bastille/bastille_3.2.1.bb
index e9accb5..0290cae 100644
--- a/recipes-security/bastille/bastille_3.2.1.bb
+++ b/recipes-security/bastille/bastille_3.2.1.bb
@@ -9,8 +9,6 @@ DEPENDS = "virtual/kernel"
 RDEPENDS_${PN} = "perl bash tcl perl-module-getopt-long perl-module-text-wrap lib-perl perl-module-file-path perl-module-mime-base64 perl-module-file-find perl-module-errno perl-module-file-glob perl-module-tie-hash-namedcapture perl-module-file-copy perl-module-english perl-module-exporter perl-module-cwd libcurses-perl coreutils"
 FILES_${PN} += "/run/lock/subsys/bastille"
 
-inherit module-base
-
 SRC_URI = "http://sourceforge.net/projects/bastille-linux/files/bastille-linux/3.2.1/Bastille-3.2.1.tar.bz2 \
            file://AccountPermission.pm \
            file://FileContent.pm \


    


Re: [meta-security][master|dunfell][PATCH 1/2] cryptsetup-tpm-incubator: RPROVIDES cryptsetup and cryptsetup-dev

Armin Kuster
 



On 7/13/20 9:00 PM, Jeremy Puhlman wrote:
From: Jeremy Puhlman <jpuhlman@...>

Without this we get weird conflict when you include dev packages:
rror: Transaction check error:
  file /usr/include/libcryptsetup.h conflicts between attempted installs of
cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
lib32-cryptsetup-dev-2.3.2-r0.1.i586
  file /usr/lib64/libcryptsetup.so conflicts between attempted installs of
cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
cryptsetup-dev-2.3.2-r0.1.corei7_64
  file /usr/lib64/pkgconfig/libcryptsetup.pc conflicts between attempted
installs of cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
cryptsetup-dev-2.3.2-r0.1.corei7_64
  file /usr/lib/libcryptsetup.so conflicts between attempted installs of
lib32-cryptsetup-tpm-incubator-dev-0.9.9-r0.i586 and
lib32-cryptsetup-dev-2.3.2-r0.1.i586
  file /usr/lib/pkgconfig/libcryptsetup.pc conflicts between attempted installs
of lib32-cryptsetup-tpm-incubator-dev-0.9.9-r0.i586 and
lib32-cryptsetup-dev-2.3.2-r0.1.i586

I plan on taking this for Dunfell. Master no long compiles do to core package updates.

not sure what I am going to do for Master yet.

thanks for the patch.
Armin
Signed-off-by: Jeremy Puhlman <jpuhlman@...>
---
 .../cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb       | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb b/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
index b706d15..2617162 100644
--- a/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
+++ b/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
@@ -36,7 +36,12 @@ FILES_${PN} += "${libdir}/tmpfiles.d"
 RDEPENDS_${PN} += "lvm2 libdevmapper"
 RRECOMMENDS_${PN} += "lvm2-udevrules"
 
+RPROVIDES_${PN} = "cryptsetup"
 RREPLACES_${PN} = "cryptsetup"
 RCONFLICTS_${PN}  ="cryptsetup"
 
+RPROVIDES_${PN}-dev = "cryptsetup-dev"
+RREPLACES_${PN}-dev = "cryptsetup-dev"
+RCONFLICTS_${PN}-dev  ="cryptsetup-dev"
+
 BBCLASSEXTEND = "native nativesdk"


    


[yocto-autobuilder2] builders.py: At the end of trigger builds use rm rather than clobber to clean up

Steve Sakoman
 

Since clobber is crossing two file systems in this case the worker
can delete the files faster than it can move them

Also fixes a occasional race that results in build failures

Signed-off-by: Steve Sakoman <steve@...>
---
builders.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/builders.py b/builders.py
index 13bfe18..778989b 100644
--- a/builders.py
+++ b/builders.py
@@ -377,9 +377,9 @@ def create_parent_builder_factory(buildername, waitname):


factory.addStep(steps.ShellCommand(
- command=[clob, util.Interpolate("{}/%(prop:buildername)s-%(prop:buildnumber)s".format(config.sharedrepodir))],
+ command=["rm", "-fr", util.Interpolate("{}/%(prop:buildername)s-%(prop:buildnumber)s".format(config.sharedrepodir))],
haltOnFailure=True,
- name="Clobber shared repo dir"))
+ name="Remove shared repo dir"))

return factory

--
2.17.1


Re: [meta-selinux][PATCH 0/4] refpolicy: update to 20200229+git

Scott Murray
 

On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
If we still keep two versions of refpolicy, it is difficult to maintain two huge local patchsets. So drop this version and only keep the git version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1 enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.
[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd. That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration. My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"
PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-targeted"

Any ideas?

Thanks,

Scott


Re: Linker error undefined reference to `_rtld_global_ro'

Khem Raj
 

On 7/14/20 12:53 AM, Robert Varga wrote:
Thank you very much for your response.

it seems static apps with glibc compiled with PIE related.

I'm afraid I didn't understand (as I am new to yocto and try to
understand it). Did you mean, the following statement in my-image.bb
file generates the static apps which is not a good approach?
SDKIMAGE_FEATURES_append = " staticdev-pkgs"

I introduced this statement because I got linking errors when
compiling/linking using the SDK complaining about missing libs just like ...
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
cannot find -lpthread
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
cannot find -ldl
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
cannot find -lstdc++
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
cannot find -lm
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
cannot find -lc
collect2: error: ld returned 1 exit status
makefile:128: recipe for target 'arm' failed
make: *** [arm] Error 1

When using this statement (SDKIMAGE_FEATURES_append = " staticdev-pkgs")
I can see in /opt/mydistro/1.0.0/sysroots/usr/lib many *.a files which
are not present without this statement. But I am not sure if this
statement is correct? Maybe there is another approach for including the
missing libs?

And what do you mean with "PIE related"? Are you thinking of an
Raspberri PI?

Can you verfiy if you get same issue with aarch64 or mips ?

Also I would like to verify, but do not know how to setup for aarch64 or
mips. Can you provide a short example?

Thank you for your support.
build SDK for arm64. e.g. MACHINE=qemuarm64 bitbake -cpopulate_sdk
core-image-sato

and install this SDK and repeat your experiment.


--

Rob



packages "shadow base-passwd" get removed at the end of do_rootfs

Jochen Behnke
 

Hello,
 
I have recipe "my-package" that
a) adds a user to the system (using "inherit useradd")
b) installs some bash-scripts
 
The my-package package is part of my image recipe and integrates without any problems.
The image also runs fine, no problems with the functionality of my-package so far.
 
But, when I try to install a newer (or the same) version of my-package on the target, rpm complains about missing dependencies.
The missing packages in the first place are
- shadow
- base-passwd
 
Querying the target rpm database (rpm -qa) confirms this, these packages are not installed (any more).
Having a look at log.do_rootfs revealed that the missing packages are installed during do_rootfs but are removed again at the end of the do_rootfs task.
Why is that?
 
I am using "thud" version of poky.
 
 
Thanks for any hint.
 
Jochen
 
 
 
 


Yocto Project Status WW28'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M2

Next Deadline: YP 3.2 M2 build date 2020/7/27

 

Next Team Meetings:

 

Key Status/Updates:

  • A key autobuilder race has been identified as a race around the bitbake lock file which will hopefully continue to reduce the number of intermittent failures being seen. It potentially explains a number of the open 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
  • We are struggling with maintainers for some key components of the system/infrastructure such as devtool, wic, buildhistory and patchwork/patchtest. If anyone can help in these areas please contact Richard.
  • Another way to help the project is to help us with bugs that are currently unassigned but ideally needed during 3.2. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs
  • We’re planning to migrate the project documentation from docbook to sphinx. If you’re interested/able to help with this please join the discussion over on the docs mailing list.

 

YP 3.2 Milestone Dates:

  • YP 3.2 M2 build date 2020/7/27
  • YP 3.2 M2 Release date 2020/8/7
  • 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.0.4 build date 2020/8/10
  • YP 3.0.4 release date 2020/8/21
  • YP 3.1.2 build date 2020/9/14
  • YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

 

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@...

 


Query regarding the use of wic image during device upgrades

Riz
 

Hi,
 
I have been using wic image format lately to create partitioned image for my device.
I was wondering if wic image format can also be used during the device upgrade scenarios?
 
After using wic image, I have an impression that it is mainly used for initially writing the wic image to sdcard/eMMC but does not support all the thinkable use cases related to device upgrade.
 
As in, for example, can we selectively upgrade any single partition in the device using the wic image?
It would be really helpful if I can get some references or pointers on this topic.
 
Thanks.


Re: Stable Warrior branch

Adrian Bunk
 

On Thu, Jun 04, 2020 at 09:28:00PM -0700, akuster wrote:
Hello,

The Warrior branch of Poky has had its last official dot release. It
will be moving to Community support and EOL within 6 weeks if no one
steps up.
If someone is interested in taking on the responsibilities of
maintaining the "Warrior" branch moving forward, please email this list.
I have an interest in keeping warrior branch alive in poky and meta-oe,
and I'll take this responsibility since noone else seems to be interested.

Please look at the
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what will
be expected.
I have some ideas, but not yet a fixed plan how I will set this up.

regards,
Armin
cu
Adrian


Re: meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mans Zigher <mans.zigher@...>
 

Thanks why I did not think of that. Anyway it works so thanks again.

BR

Den tis 14 juli 2020 kl 14:12 skrev <Mikko.Rapeli@...>:


Hi,

On Tue, Jul 14, 2020 at 02:08:37PM +0200, Mans Zigher wrote:
I figured it out the problem was that in meta-layer1 we had
SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
apparently will always be added to the end of SRC_URI list and
thereby the meta-layer2 patches will be applied first. Is it possible
to get machine specific patches applied first?
You can try with SRC_URI_prepend_machine1.

Cheers,

-Mikko


Re: meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mikko Rapeli
 

Hi,

On Tue, Jul 14, 2020 at 02:08:37PM +0200, Mans Zigher wrote:
I figured it out the problem was that in meta-layer1 we had
SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
apparently will always be added to the end of SRC_URI list and
thereby the meta-layer2 patches will be applied first. Is it possible
to get machine specific patches applied first?
You can try with SRC_URI_prepend_machine1.

Cheers,

-Mikko


Re: meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mans Zigher <mans.zigher@...>
 

I figured it out the problem was that in meta-layer1 we had
SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
apparently will always be added to the end of SRC_URI list and
thereby the meta-layer2 patches will be applied first. Is it possible
to get machine specific patches applied first?

BR

Den tis 14 juli 2020 kl 13:29 skrev zigext <mans.zigher@...>:


I have debugged cooker.py and everything looks good it produces a list
of the bbappend files that matches the expected result so something is
screwing it up when the recipe is baked since I can see that the order
is wrong when dumping the environment for the virtual/kernel.

BR

Den tis 14 juli 2020 kl 11:21 skrev zigext <mans.zigher@...>:

Hi,

I am using thud for my distro and I have two bbappend for my kernel I
need to make sure that meta-layer1 is parsed before meta-layer2 to get
the patches applied in the right order. So the patches in meta-layer2
need to be applied after meta-layer1 patches have been applied. I have
adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
has 1110 based on "A larger value for the BBFILE_PRIORITY variable
results in a higher precedence." but whatever I do I am still getting
the wrong order and do_patch is failing. Any pointers to what I am
doing wrong? I must be doing something wrong that is preventing the
BBFILE_PRIORITY in my layer.conf to have an effect. Running
"bitbake-layers show-layers" shows the expected output but when
running the do_patch it is wrong and when dumping the env using
"bitbake -e virtual/kernel" it is clear the order is wrong.

BR


Re: meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mans Zigher <mans.zigher@...>
 

I have debugged cooker.py and everything looks good it produces a list
of the bbappend files that matches the expected result so something is
screwing it up when the recipe is baked since I can see that the order
is wrong when dumping the environment for the virtual/kernel.

BR

Den tis 14 juli 2020 kl 11:21 skrev zigext <mans.zigher@...>:


Hi,

I am using thud for my distro and I have two bbappend for my kernel I
need to make sure that meta-layer1 is parsed before meta-layer2 to get
the patches applied in the right order. So the patches in meta-layer2
need to be applied after meta-layer1 patches have been applied. I have
adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
has 1110 based on "A larger value for the BBFILE_PRIORITY variable
results in a higher precedence." but whatever I do I am still getting
the wrong order and do_patch is failing. Any pointers to what I am
doing wrong? I must be doing something wrong that is preventing the
BBFILE_PRIORITY in my layer.conf to have an effect. Running
"bitbake-layers show-layers" shows the expected output but when
running the do_patch it is wrong and when dumping the env using
"bitbake -e virtual/kernel" it is clear the order is wrong.

BR


meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mans Zigher <mans.zigher@...>
 

Hi,

I am using thud for my distro and I have two bbappend for my kernel I
need to make sure that meta-layer1 is parsed before meta-layer2 to get
the patches applied in the right order. So the patches in meta-layer2
need to be applied after meta-layer1 patches have been applied. I have
adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
has 1110 based on "A larger value for the BBFILE_PRIORITY variable
results in a higher precedence." but whatever I do I am still getting
the wrong order and do_patch is failing. Any pointers to what I am
doing wrong? I must be doing something wrong that is preventing the
BBFILE_PRIORITY in my layer.conf to have an effect. Running
"bitbake-layers show-layers" shows the expected output but when
running the do_patch it is wrong and when dumping the env using
"bitbake -e virtual/kernel" it is clear the order is wrong.

BR


Re: Linker error undefined reference to `_rtld_global_ro'

Robert Varga
 

Thank you very much for your response.

it seems static apps with glibc compiled with PIE related.
I'm afraid I didn't understand (as I am new to yocto and try to understand it). Did you mean, the following statement in my-image.bb file generates the static apps which is not a good approach?
SDKIMAGE_FEATURES_append = " staticdev-pkgs"

I introduced this statement because I got linking errors when compiling/linking using the SDK complaining about missing libs just like ...
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -lpthread
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -ldl
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -lstdc++
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -lm
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -lc
collect2: error: ld returned 1 exit status
makefile:128: recipe for target 'arm' failed
make: *** [arm] Error 1

When using this statement (SDKIMAGE_FEATURES_append = " staticdev-pkgs") I can see in /opt/mydistro/1.0.0/sysroots/usr/lib many *.a files which are not present without this statement. But I am not sure if this statement is correct? Maybe there is another approach for including the missing libs?

And what do you mean with "PIE related"? Are you thinking of an Raspberri PI?

Can you verfiy if you get same issue with aarch64 or mips ?
Also I would like to verify, but do not know how to setup for aarch64 or mips. Can you provide a short example?

Thank you for your support.

--

Rob


[meta-security][master|dunfell][PATCH 2/2] packagegroup-security-tpm2: Depend on preferred provider for cryptsetup

Jeremy Puhlman
 

From: Jeremy Puhlman <jpuhlman@...>

Signed-off-by: Jeremy Puhlman <jpuhlman@...>
---
meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
index 8f5c537..a553a63 100644
--- a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
+++ b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
@@ -7,6 +7,7 @@ inherit packagegroup

PACKAGES = "${PN}"

+PREFERRED_PROVIDER_cryptsetup ?= "cryptsetup-tpm-incubator"
SUMMARY_packagegroup-security-tpm2 = "Security TPM 2.0 support"
RDEPENDS_packagegroup-security-tpm2 = " \
tpm2-tools \
@@ -19,5 +20,5 @@ RDEPENDS_packagegroup-security-tpm2 = " \
tpm2-abrmd \
tpm2-pkcs11 \
ibmswtpm2 \
- cryptsetup-tpm-incubator \
+ ${PREFERRED_PROVIDER_cryptsetup} \
"
--
1.8.2.3

7841 - 7860 of 57784