For core-updates.

For core-updates.

[John Darrington]

This patch fixes a number of failures in core-updates.  I don't know
if there is a better way of doing it, or why it is suddenly necessary.

gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[John Darrington]

* gnu/packages/fontutils.scm (arguments)[configure-flags]: Add LDFLAGS=lpthread.
* gnu/packages/image.scm (arguments)[configure-flags]: Add LDFLAGS=lpthread.
---
 gnu/packages/fontutils.scm | 1 +
 gnu/packages/image.scm     | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/gnu/packages/fontutils.scm b/gnu/packages/fontutils.scm
index 7e7234960..2512626d2 100644
--- a/gnu/packages/fontutils.scm
+++ b/gnu/packages/fontutils.scm
@@ -56,6 +56,7 @@
             (sha256 (base32
                      "121gm15ayfg3rglby8ifh8384mcjb9dhmx9j40zl7yszw72b4frs"))))
    (build-system gnu-build-system)
+   (arguments `(#:configure-flags '("LDFLAGS=-lpthread")))
    (native-inputs
     `(("pkg-config" ,pkg-config)))
    (propagated-inputs
diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index 2989ea006..5280f477d 100644
--- 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")))
 
    ;; libpng.la says "-lz", so propagate it.
    (propagated-inputs `(("zlib" ,zlib)))
-- 
2.11.0

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Tue, Mar 21, 2017 at 02:22:11AM +0100, John Darrington wrote:
> * gnu/packages/fontutils.scm (arguments)[configure-flags]: Add LDFLAGS=lpthread.
> * gnu/packages/image.scm (arguments)[configure-flags]: Add LDFLAGS=lpthread.

I'll wait for somebody else to review the code changes (I don't
understand their impact), but the commit message should be like this:

* gnu/packages/fontutils.scm (PACKAGE)[arguments]: Add LDFLAGS=lpthread
to #:configure-flags.

et cetera

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

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.

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

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.

J'



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[Danny Milosavljevic]

Hi John,

thanks for looking into the problem.

On Tue, 21 Mar 2017 02:22:11 +0100
John Darrington <john@darrington.wattle.id.au> wrote:
> +   (arguments `(#:configure-flags '("LDFLAGS=-lpthread")))

Hmm, that seems to be a very unsafe thing to do.

In order to actually use pthread, one has to switch gcc into pthread mode (which influences how it handles variables etc).
But just passing "-lpthread" to the linker does no such things and will only make it link - with the wrong actual instructions in the object files!

Also, even if it worked - by chance -, that seems like papering over the problem.

It would be better to check out the object files (with objdump -r or objdump -t) and find out where the symbol is listed as undefined ("U"). Then check the associated source file whether it actually intended to use pthread.

Pthread is not exactly a modular library that you can just switch on and off at will.

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

On Tue, Mar 21, 2017 at 12:29:05PM +0100, Danny Milosavljevic wrote:
     Hi John,
     
     thanks for looking into the problem.
     
     On Tue, 21 Mar 2017 02:22:11 +0100
     John Darrington <john@darrington.wattle.id.au> wrote:
     > +   (arguments `(#:configure-flags '("LDFLAGS=-lpthread")))
     
     Hmm, that seems to be a very unsafe thing to do.

I was afraid you might say that.
     
     In order to actually use pthread, one has to switch gcc into pthread mode (which influences how it handles variables etc).
     But just passing "-lpthread" to the linker does no such things and will only make it link - with the wrong actual instructions in the object files!

It used to work.   Only recently has it stopped working.
So that would seem to confirm to me that a version of gcc (or some other part of
the tool chain) recently checked into core-updates might have been misconfigured.
Is it possible that somehow pthread mode has been inadvertently switched on?
     
     
     It would be better to check out the object files (with objdump -r or objdump -t) and find out where the symbol is listed as undefined ("U"). Then check the associated source file whether it actually intended to use pthread.

I'm not familiar enough with the internals to know exactly which source file 
would be involved.  But the error message clearly says to relink libpng and libfontconfig 
using -lpthread.  I just did as told.

J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[Danny Milosavljevic]

Hi,

I forgot to say: gcc pthread mode is activated via option "-pthread".

It enables thread-local storage for some things (errno etc) and uses reentrant versions of some functions.

Which packages are the ones that is depending on libpng and failing?  I can have a look...

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 3418 bytes --]

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

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH] gnu: Add LDFLAGS=-lpthread to configure-flags where needed.

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Tue, 21 Mar 2017 22:42:49 +0000
Sergei Trofimovich <slyfox@inbox.ru> wrote:

> 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.

Found existing one:
    https://sourceware.org/bugzilla/show_bug.cgi?id=21041

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]