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
