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