On Wed, Jan 11, 2017 at 7:56 AM, Phil Blundell <p...@pbcl.net> wrote: > On Wed, 2017-01-11 at 12:19 +0000, Burton, Ross wrote: > > > On 11 January 2017 at 03:51, Khem Raj <raj.k...@gmail.com> wrote: > > Signed-off-by: Khem Raj <raj.k...@gmail.com> > > > This fails when building gdk-pixbuf for x86-64 with gobject-introspection > enabled: > > | > /data/poky-master/tmp-glibc/work/corei7-64-poky-linux/gdk-pixbuf/2.36.1-r0/build/gdk-pixbuf/tmp-introspectylz98kc7/.libs/GdkPixbuf-2.0: > Relink > `/data/poky-master/tmp-glibc/sysroots/intel-corei7-64//usr/lib/libpng16.so.16' > with > `/data/poky-master/tmp-glibc/sysroots/intel-corei7-64//lib/libpthread.so.0' > for IFUNC symbol `longjmp' > > > The gdk-pixbuf link does use -lpthread, is this saying that libpng should be > linked against pthread too? I can replicate on demand if you have any > suggestions. > > > That's what it's saying, and this was introduced by the fix for: > > https://sourceware.org/bugzilla/show_bug.cgi?id=20019 > > But I think this new behaviour is in itself a bug. It isn't reasonable to > expect any library that calls longjmp() to link -lpthread just in case it > might end up coexisting with another library that does. (The fact that > libpthread defines longjmp is arguably a bug in itself, but one that we are > stuck with.)
This is showing when executing target binaries in qemu here I believe. One workaround we could try is to use LD_PRELOAD of libpthread.so.0, that might get us over this error, but the issue still may manifest on target apps using libpng16 with other library pulling in libpthread > > p. > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
