GNU bug report logs - #38405
[staging] Some Qt plugins fail to build

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38405 in the body.
You can then email your comments to 38405 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: bug-guix <at> gnu.org
Subject: [staging] Some Qt plugins fail to build
Date: Wed, 27 Nov 2019 19:06:11 +0100

[Message part 1 (text/plain, inline)]

Hello Guix,

The 'staging' branch has been idle for a while because some Qt packages
fail to build (as of commit b60d2bfff95c0859d7814c1fe9d0940c87edc2b4):

* qtwayland: https://ci.guix.gnu.org/build/1851111/details
* qtgamepad: https://ci.guix.gnu.org/build/1946382/details
* qtwebglplugin: https://ci.guix.gnu.org/build/1830705/details

Unfortunately none of the above log files show the real issue because of
truncation: <https://bugs.gnu.org/37246>.

The problem is that for these packages specifically, the Makefile
generated by qmake references $out/lib/libQt5Core.so in LIBS (in
_addition_ to $qtbase/lib/libQt5Core.so), which in turn breaks the GCC
command line because $out/lib/libQt5Core.so obviously does not exist.

Prior to Qt 5.12, qmake generated LIBS by adding appropriate -L and -l
arguments to GCC such as "-L /gnu/store/abc123-foo/lib -l foo", whereas Qt
5.12 inserts absolute library references, i.e.
"/gnu/store/abc123-foo/lib/libfoo.so".  The former case worked because
GCC gracefully handles duplicate -L and -l arguments as long as at least
one of the '-L's are sane.

The references comes from the .prl files shipped with qtbase, which
contains entries such as:

  QMAKE_PRL_LIBS = $$[QT_INSTALL_LIBS]/libQt5Gui.so $$[QT_INSTALL_LIBS]/libQt5Core.so -lpthread /gnu/store/hhpkqcz4i8rsv3lk1iv694q0bkg2vij9-mesa-19.2.1/lib/libGL.so

QT_INSTALL_LIBS behaves differently in Guix at "configure time" (qmake)
and "build time" (when running "make", which creates other Makefiles).
At configure time it correctly resolves to the qtbase output (because we
patch qt_configure.prf to make it so).  At build time, it is repurposed
to be the installation prefix (i.e. $out/lib).

It's not clear to me why only the three mentioned packages are
affected.  My current best guess is that they fail to probe for some
(transitive?) dependency at "configure time", so no qmake cache entry is
created.  When these dependencies are resolved at "build time",
QT_INSTALL_LIBS points to the wrong location, and the build fails.

A workaround for this issue will be submitted shortly.

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 38405 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: 38405 <at> debbugs.gnu.org
Subject: [PATCH] gnu: qtbase: Use absolute references in .prl files.
Date: Wed, 27 Nov 2019 19:11:28 +0100

This fixes <https://bugs.gnu.org/38405>.

* gnu/packages/qt.scm (qtbase)[arguments]: Add phase 'patch-prl-files'.
---
 gnu/packages/qt.scm | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index 5f4f29a948..2cc44ab831 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -509,6 +509,16 @@ developers using C++ or QML, a CSS & JavaScript like language.")
                  (("\\$\\$\\[QT_HOST_DATA/get\\]") archdata)
                  (("\\$\\$\\[QT_HOST_DATA/src\\]") archdata))
                #t)))
+         (add-after 'patch-mkspecs 'patch-prl-files
+           (lambda* (#:key outputs #:allow-other-keys)
+             (let ((out (assoc-ref outputs "out")))
+               ;; Insert absolute references to the qtbase libraries because
+               ;; QT_INSTALL_LIBS does not always resolve correctly, depending
+               ;; on context.  See <https://bugs.gnu.org/38405>
+               (substitute* (find-files (string-append out "/lib") "\\.prl$")
+                 (("\\$\\$\\[QT_INSTALL_LIBS\\]")
+                  (string-append out "/lib")))
+               #t)))
          (add-after 'unpack 'patch-paths
            ;; Use the absolute paths for dynamically loaded libs, otherwise
            ;; the lib will be searched in LD_LIBRARY_PATH which typically is
-- 
2.24.0

Message #13 received at 38405-done <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: 38405-done <at> debbugs.gnu.org
Subject: Re: bug#38405: [PATCH] gnu: qtbase: Use absolute references in .prl
 files.
Date: Thu, 28 Nov 2019 00:18:13 +0100

[Message part 1 (text/plain, inline)]

Marius Bakke <mbakke <at> fastmail.com> writes:

> This fixes <https://bugs.gnu.org/38405>.
>
> * gnu/packages/qt.scm (qtbase)[arguments]: Add phase 'patch-prl-files'.

[...]

> +         (add-after 'patch-mkspecs 'patch-prl-files
> +           (lambda* (#:key outputs #:allow-other-keys)
> +             (let ((out (assoc-ref outputs "out")))
> +               ;; Insert absolute references to the qtbase libraries because
> +               ;; QT_INSTALL_LIBS does not always resolve correctly, depending
> +               ;; on context.  See <https://bugs.gnu.org/38405>
> +               (substitute* (find-files (string-append out "/lib") "\\.prl$")
> +                 (("\\$\\$\\[QT_INSTALL_LIBS\\]")
> +                  (string-append out "/lib")))
> +               #t)))

I pushed this hunk in a59e2dd8cd16655e379abb567baf978c94f3d48e, as I'm
fairly confident that this is the right thing to do.

Feedback still welcome however.  :-)

[signature.asc (application/pgp-signature, inline)]

Message #16 received at 38405 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 38405 <at> debbugs.gnu.org
Subject: Re: bug#38405: [PATCH] gnu: qtbase: Use absolute references in .prl
 files.
Date: Thu, 28 Nov 2019 12:26:52 +0200

[Message part 1 (text/plain, inline)]

As I'm sure you noticed, with your patch I was able to build qtwayland.


-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.