Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Patrick Ohly]

On Thu, 2018-03-08 at 19:18 -0600, Mark Hatle wrote:
> Yes, the dlopen means the automated processing can't identify the
> need.. and
> then the RDEPEND is the correct solution.
> 
> (This might be a reasonable bug/enhancement request to the
> system.  Look for
> pthread_cancel and automatically infer that libgcc is required.)

There is already a feature request for that:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10954

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Mark Hatle]

On 3/8/18 4:10 PM, Marcelo E. Magallon wrote:
> On Thu, Mar 08, 2018 at 03:16:44PM -0600, Mark Hatle wrote:
> 
>> 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.
> 
> INHIBIT_DEFAULT_DEPS.
> 
> No, it doesn't, but that's a good hint.
> 
>> 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.)
> 
> This is also the case in this situation.
> 
> glibc has this bit of code in pthread_cancel_init:
> 
> handle = __libc_dlopen_mode (LIBGCC_S_SO, RTLD_NOW | __RTLD_DLOPEN);
>   
> if (handle == NULL
> || (resume = __libc_dlsym (handle, "_Unwind_Resume")) == NULL
> || (personality = __libc_dlsym (handle, "__gcc_personality_v0")) 
> == NULL
> || (forcedunwind = __libc_dlsym (handle, "_Unwind_ForcedUnwind"))
>== NULL
> || (getcfa = __libc_dlsym (handle, "_Unwind_GetCFA")) == NULL
>   #ifdef ARCH_CANCEL_INIT
> || ARCH_CANCEL_INIT (handle)
>   #endif
> )
>   __libc_fatal (LIBGCC_S_SO " must be installed for pthread_cancel to 
> work\n");
> 
> it's dlopen()ing libgcc_s.so.1 in order to get thread 
> cancellation to work via exception unwinding.

Yes, the dlopen means the automated processing can't identify the need.. and
then the RDEPEND is the correct solution.

(This might be a reasonable bug/enhancement request to the system.  Look for
pthread_cancel and automatically infer that libgcc is required.)

> In my case, libgcc_s.so.1 is installed in the image before adding 
> the RDEPENDS.
> 
> What doesn't make sense to me is why in both the OP's and my 
> case, adding RDEPENDS_${PN} += "libgcc" is fixing anything. As 
> you said, this is promoted to a DEPENDS, so libgcc is available 
> at compile time, but that shouldn't change anything that I can 
> see.

I'm guessing if it's not available at compile time that some behavior is
changing (maybe not using pthread_cancel?)

Not sure... but at least the reason the RDEPEND resolves the runtime issue is
now clear to me, and within the design.

--Mark

> Thanks for looking at this,
> 
> Marcelo
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Marcelo E. Magallon]

On Thu, Mar 08, 2018 at 01:30:28PM -0800, robert_jos...@selinc.com wrote:


In the case of btrfs-tools, it was simply that it needed libgcc_s.so.1 at
runtime on the target, which my patch fixed. For me, the image I was
building normally worked fine because some other package would pull in
libgcc, but when testing on a minimal image, I would get that error. I'm
not sure about your specific case. If you do have libgcc on the target, an
application that needs it doesn't really care what package pulled it into
the image, all that matters is that it's installed.


Ah, that makes sense in your case. Thanks for clarifying!

Marcelo
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Marcelo E. Magallon]

On Thu, Mar 08, 2018 at 03:16:44PM -0600, Mark Hatle wrote:


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.


INHIBIT_DEFAULT_DEPS.

No, it doesn't, but that's a good hint.


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


This is also the case in this situation.

glibc has this bit of code in pthread_cancel_init:

  handle = __libc_dlopen_mode (LIBGCC_S_SO, RTLD_NOW | __RTLD_DLOPEN);

  if (handle == NULL
  || (resume = __libc_dlsym (handle, "_Unwind_Resume")) == NULL
  || (personality = __libc_dlsym (handle, "__gcc_personality_v0")) 
== NULL
  || (forcedunwind = __libc_dlsym (handle, "_Unwind_ForcedUnwind"))
 == NULL
  || (getcfa = __libc_dlsym (handle, "_Unwind_GetCFA")) == NULL
#ifdef ARCH_CANCEL_INIT
  || ARCH_CANCEL_INIT (handle)
#endif
  )
__libc_fatal (LIBGCC_S_SO " must be installed for pthread_cancel to 
work\n");

it's dlopen()ing libgcc_s.so.1 in order to get thread 
cancellation to work via exception unwinding.


In my case, libgcc_s.so.1 is installed in the image before adding 
the RDEPENDS.


What doesn't make sense to me is why in both the OP's and my 
case, adding RDEPENDS_${PN} += "libgcc" is fixing anything. As 
you said, this is promoted to a DEPENDS, so libgcc is available 
at compile time, but that shouldn't change anything that I can 
see.


Thanks for looking at this,

Marcelo
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[robert_joslyn]

"Marcelo E. Magallon" <marcelo.magal...@hpe.com> wrote on 03/08/2018 
01:00:28 PM:

> From: "Marcelo E. Magallon" <marcelo.magal...@hpe.com>
> To: <robert_jos...@selinc.com>, 
> Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
> Date: 03/08/2018 01:01 PM
> Subject: Re: [yocto] btrfs-tools Requires libgcc_s.so.1
> 
> 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.

Your understanding is basically correct, RDEPENDS specifies a runtime 
dependency. For btrfs-tools, it doesn't change the build, it simply makes 
sure that the libgcc package is installed on the target if btrfs-tools is 
also installed on the target. If there is more going on with RDEPENDS 
besides the final rpm/ipk/deb packaging, someone with more bitbake 
knowledge will have to provide more information.

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

In the case of btrfs-tools, it was simply that it needed libgcc_s.so.1 at 
runtime on the target, which my patch fixed. For me, the image I was 
building normally worked fine because some other package would pull in 
libgcc, but when testing on a minimal image, I would get that error. I'm 
not sure about your specific case. If you do have libgcc on the target, an 
application that needs it doesn't really care what package pulled it into 
the image, all that matters is that it's installed.

Robert

> 
> Any clues?
> 
> Thanks!
> 
> Marcelo
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Mark Hatle]

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

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Marcelo E. Magallon]

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


Any clues?

Thanks!

Marcelo
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[robert_joslyn]

"Burton, Ross"  wrote on 03/04/2016 04:17:53 PM:
> Would you be able to send that to the oe-core list (openembedded-
> c...@lists.openembedded.org) using git-send-email (ideally, 
> attaching the output of git format-patch will do) to get your 
> authorship transferred correctly?  That's the formal process.

Sure, I'll send it along.

Thanks,
Robert
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Burton, Ross]

On 5 March 2016 at 00:12,  wrote:

> What is the process for getting this fixed upstream? Trivial patch is
> below, if that is sufficient.
>

Would you be able to send that to the oe-core list (
openembedded-c...@lists.openembedded.org) using git-send-email (ideally,
attaching the output of git format-patch will do) to get your authorship
transferred correctly?  That's the formal process.

Thanks,
Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[robert_joslyn]

Khem Raj  wrote on 03/04/2016 03:26:37 PM:
> 
> On Sat, Mar 5, 2016 at 7:17 AM,   wrote:
> > I'm building an image using btrfs and I noticed a problem with the
> > btrfs-tools recipe in Jethro (using core-image-minimal and a 64-bit
> > machine). The recipe builds fine, but I get the following error when
> > attempting certain operations using btrfs, such as trying to start a
> > scrub:
> >
> > 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.
> 
> thats fine.

What is the process for getting this fixed upstream? Trivial patch is 
below, if that is sufficient.

Signed-off-by: Robert Joslyn 
---
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"

 SRCREV = "7f1328ccb5d159efe850d4eaea9b49bbe8c4181e"
 SRC_URI = 
"git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git \
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Khem Raj]

On Sat, Mar 5, 2016 at 7:17 AM,   wrote:
> I'm building an image using btrfs and I noticed a problem with the
> btrfs-tools recipe in Jethro (using core-image-minimal and a 64-bit
> machine). The recipe builds fine, but I get the following error when
> attempting certain operations using btrfs, such as trying to start a
> scrub:
>
> 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.

thats fine.

 I'm not
> very familiar with libgcc, but is this just an oversight, or is there some
> reason it was not included?

its dlopened in this case I think thats why it has to  explicitly
called out as rdep.

Should it be statically linked instead?

no
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto