On 3/8/18 3:00 PM, Marcelo E. Magallon wrote: > Sorry to go off on a tangent: > > On Fri, Mar 04, 2016 at 04:12:54PM -0800, robert_jos...@selinc.com wrote: > >>>> root@test:~# btrfs scrub start / >>>> scrub started on /, fsid 79dc4fed-a0f7-43e2-b9e7-056b1a2c4cdd >> (pid=333) >>>> libgcc_s.so.1 must be installed for pthread_cancel to work >>>> >>>> I can solve this by adding libgcc to RDEPENDS for btrfs-tools. > > I ran into the same thing with my device, different package. I > don't understand the fix: > >> Signed-off-by: Robert Joslyn <robert_jos...@selinc.com> >> --- >> diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb >> b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb >> index 37c622b..cc2ccfc 100644 >> --- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb >> +++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb >> @@ -11,6 +11,7 @@ LICENSE = "GPLv2" >> LIC_FILES_CHKSUM = "file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067" >> SECTION = "base" >> DEPENDS = "util-linux attr e2fsprogs lzo acl" >> +RDEPENDS_${PN} = "libgcc" > > What is this doing? > > My understanding until a couple of days ago is that this will > simply pull the "libgcc" package into the image, add a dependency > in the binary package and NOTHING more. It won't change the way > binaries are linked, it won't change flags passed to the > compiler, etc. > > I'm confused because in my case libgcc_s.so.1 is already in the > image, before this change, but this change seems to be fixing the > issue, and I don't understand why.
RDEPENDS are automatically promoted to DEPENDS (build-time). I would normally expect libgcc_s.so.1 to be present via the typical default depends. Does your recipe have an INHIBIT_DEFAULT_DEPENDS (I think that is it?) defined? If so, you would need to manually add all build dependencies then. An executable or library with a stated library dependency (soname) will automatically get an RDEPENDS. The only time you should have to do an RDEPENDS_${PN} of a library is when that library is 'dlopened'. (This is the case for things like pam modules.) --Mark > Any clues? > > Thanks! > > Marcelo > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto