On Tue, 21 Mar 2017 10:17:26 +0100
John Darrington <john@darrington.wattle.id.au> wrote:

> On Tue, Mar 21, 2017 at 09:09:28AM +0000, Sergei Trofimovich wrote:
>      On Tue, 21 Mar 2017 02:22:11 +0100
>      John Darrington <john@darrington.wattle.id.au> wrote:
>      
>      > --- a/gnu/packages/image.scm
>      > +++ b/gnu/packages/image.scm
>      > @@ -80,6 +80,8 @@
>      >              (sha256
>      >               (base32 "0ylgyx93hnk38haqrh8prd3ax5ngzwvjqw5cxw7p9nxmwsfyrlyq"))))
>      >     (build-system gnu-build-system)
>      > +   (arguments
>      > +    `(#:configure-flags '("LDFLAGS=-lpthread")))  
>      
>      That's libpng-1.6.28, right? I've tried to reproduce the failure on current
>      'core-updates' master (x86_64-linux). It builds just fine:
>      
>      $ git describe
>      v0.12.0-2306-gf826c8c7e
>      
>      $ ./pre-inst-env guix build libpng --check --no-grafts -K
>      /gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28
>      
>      At a glance source code of libpng and it's tests does not contain any pthread calls.
>      
>      Do you have a build log with the failure? I wonder where missing symbols come from.
>      
> 
> Yes *IT* builds fine.  It's just the thing that depend upon it that don't.
> For example look at the most recent build attempt for pspp.

Aha. I was not sure where to look at. Assuming hydra build at:
    https://hydra.gnu.org/jobset/gnu/core-updates#tabs-jobs

I've filtered on 'pspp' in there.

amd64 and i686 fail roughly the same at test phase. Linking phase looks OK.
    https://hydra.gnu.org/build/1927214/nixlog/1/raw
    https://hydra.gnu.org/build/1930649/nixlog/1/raw

Looks exactly as local build failure on master for me.

To get an error text you are fixing I looked at test failures.

For example /tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/tests/testsuite.dir/0001/testsuite.log

That runs something like ../../../src/ui/terminal/pspp --testing-mode --error-file=- --no-output epoch.sps

  #                             -*- compilation -*-
  1. calendar.at:3: testing epoch ...
  ./calendar.at:89: pspp --testing-mode --error-file=- --no-output epoch.sps
  --- /dev/null   2017-02-25 15:55:49.604311111 +0000
  +++ /tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/tests/testsuite.dir/at-groups/1/stderr        2017-03-21 22:02:35.240095562 +0000
  @@ -0,0 +1,2 @@
  +/tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/src/ui/terminal/.libs/pspp: Relink `/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp'
  +/tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/src/ui/terminal/.libs/pspp: Relink `/gnu/store/b837wr8ffw2ppbx1744a2xll70bh8h4c-freetype-2.7.1/lib/libfreetype.so.6' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp'
  1. calendar.at:3: 1. epoch (calendar.at:3): FAILED (calendar.at:89)

It's a glibc-2.25 change that added runtime checking of IFUNC functions.
(Functions that choose their implementation at application load time)

Looks like a glibc bug.

The behaviour was introduced in
    https://sourceware.org/bugzilla/show_bug.cgi?id=20019

I'll try to write minimal reproducer with setjmp/longjmp and report it upstream.

-- 

  Sergei