[OE-core] [PATCH 2/2] glibc: Upgrade to 2.25

[Khem Raj]

On Wed, Jan 11, 2017 at 7:56 AM, Phil Blundell <pb at 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.khem at gmail.com> wrote:
>
> Signed-off-by: Khem Raj <raj.khem at 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.
>