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
