[PATCH] Patch Qt 5.4 for i686.

[PATCH] Patch Qt 5.4 for i686.

[Taylan Ulrich Bayırlı/Kammer]

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

It will take my machine another ~7 hours to build Qt so that I can
verify that this works; on the meanwhile sending it in FYI and for
stylistic review.


[-- Attachment #2: 0001-Patch-Qt-5.4-for-i686.patch --]
[-- Type: text/x-diff, Size: 3952 bytes --]

From eb8f5f90684e141c4055c9e484629a2c7d731a06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
 <taylanbayirli@gmail.com>
Date: Fri, 24 Apr 2015 10:43:57 +0200
Subject: [PATCH] Patch Qt 5.4 for i686.

See <https://bugreports.qt.io/browse/QTBUG-45205>.

* gnu/packages/patches/qt5-conflicting-typedefs.patch: New file.
* gnu-system.am (dist_patch_DATA): Add it.
* gnu/packages/qt.scm (qt): Add the patch.
---
 gnu-system.am                                      |  1 +
 .../patches/qt5-conflicting-typedefs.patch         | 45 ++++++++++++++++++++++
 gnu/packages/qt.scm                                |  3 +-
 3 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/qt5-conflicting-typedefs.patch

diff --git a/gnu-system.am b/gnu-system.am
index 13d06fb..8e5d43b 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -526,6 +526,7 @@ dist_patch_DATA =						\
   gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch \
   gnu/packages/patches/qt4-ldflags.patch			\
   gnu/packages/patches/qt4-tests.patch				\
+  gnu/packages/patches/qt5-conflicting-typedefs.patch		\
   gnu/packages/patches/qt5-runpath.patch			\
   gnu/packages/patches/ratpoison-shell.patch			\
   gnu/packages/patches/readline-link-ncurses.patch		\
diff --git a/gnu/packages/patches/qt5-conflicting-typedefs.patch b/gnu/packages/patches/qt5-conflicting-typedefs.patch
new file mode 100644
index 0000000..f96390e
--- /dev/null
+++ b/gnu/packages/patches/qt5-conflicting-typedefs.patch
@@ -0,0 +1,45 @@
+From 5c45e53ee2f8ab39f3471eaf5f9636c68f3c3960 Mon Sep 17 00:00:00 2001
+From: Andras Becsi <andras.becsi@theqtcompany.com>
+Date: Wed, 11 Mar 2015 13:15:30 +0100
+Subject: <third_party/mesa> Fix conflicting declaration errors due to
+ duplicate typedefs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Due to cascading includes to QtWebEngine core GLintptr and GLsizeiptr
+might end up being defined twice if compiling with some embedded
+toolchains like for the colibri-vf setup, due to chromium's
+gles2_cmd_format.h also defining these typedefs unconditionally.
+Prevent the conflicting definitions by guarding them with
+BUILDING_CHROMIUM which we define when compiling QtWebEngineCore.
+
+Change-Id: I33719c08300211f4ad304efa3e7a5326136bb3cf
+Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com>
+---
+ chromium/third_party/mesa/src/include/GL/glext.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/chromium/third_party/mesa/src/include/GL/glext.h b/chromium/third_party/mesa/src/include/GL/glext.h
+index cb19ed4..1b78767 100644
+--- a/chromium/third_party/mesa/src/include/GL/glext.h
++++ b/chromium/third_party/mesa/src/include/GL/glext.h
+@@ -6148,6 +6148,7 @@ typedef char GLchar;
+ #endif
+ 
+ #ifndef GL_VERSION_1_5
++#ifndef BUILDING_CHROMIUM
+ /* GL types for handling large vertex buffer objects */
+ #ifdef _WIN64
+ typedef signed   long long int GLintptr;
+@@ -6157,6 +6158,7 @@ typedef signed   long  int     GLintptr;
+ typedef signed   long  int     GLsizeiptr;
+ #endif
+ #endif
++#endif
+ 
+ #ifndef GL_ARB_vertex_buffer_object
+ /* GL types for handling large vertex buffer objects */
+-- 
+cgit v0.11.0
+
diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index 8de1ffe..3bc3145 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -104,7 +104,8 @@ X11 (yet).")
              (sha256
               (base32
                "0q6qzakq8xihw91xv310qi3vyylq7x2bzdkjgy8sqxii2lgbjzhv"))
-             (patches (list (search-patch "qt5-runpath.patch")))
+             (patches (list (search-patch "qt5-conflicting-typedefs.patch")
+                            (search-patch "qt5-runpath.patch")))
              (snippet
               '(begin
                  ;; Remove broken symlinks.
-- 
2.2.1

Re: [PATCH] Patch Qt 5.4 for i686.

[Taylan Ulrich Bayırlı/Kammer]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> It will take my machine another ~7 hours to build Qt so that I can
> verify that this works; on the meanwhile sending it in FYI and for
> stylistic review.

The patch does not solve the problem after all. :-(

I should have taken a closer look; this patches the in-tree Mesa
headers, which are of course not used when building with system Mesa.

I will investigate further but don't hold your breath.  Although in
worst case we could build with Qt's in-tree copy of Mesa.

Taylan

Re: [PATCH] Patch Qt 5.4 for i686.

[Mark H Weaver]

Hi Taylan,

Thank you for your continued work on this, but...

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> From eb8f5f90684e141c4055c9e484629a2c7d731a06 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  <taylanbayirli@gmail.com>
> Date: Fri, 24 Apr 2015 10:43:57 +0200
> Subject: [PATCH] Patch Qt 5.4 for i686.
>
> See <https://bugreports.qt.io/browse/QTBUG-45205>.
[...]
> diff --git a/gnu/packages/patches/qt5-conflicting-typedefs.patch b/gnu/packages/patches/qt5-conflicting-typedefs.patch
> new file mode 100644
> index 0000000..f96390e
> --- /dev/null
> +++ b/gnu/packages/patches/qt5-conflicting-typedefs.patch
> @@ -0,0 +1,45 @@
> +From 5c45e53ee2f8ab39f3471eaf5f9636c68f3c3960 Mon Sep 17 00:00:00 2001
> +From: Andras Becsi <andras.becsi@theqtcompany.com>
> +Date: Wed, 11 Mar 2015 13:15:30 +0100
> +Subject: <third_party/mesa> Fix conflicting declaration errors due to
> + duplicate typedefs
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Due to cascading includes to QtWebEngine core GLintptr and GLsizeiptr
> +might end up being defined twice if compiling with some embedded
> +toolchains like for the colibri-vf setup, due to chromium's
> +gles2_cmd_format.h also defining these typedefs unconditionally.
> +Prevent the conflicting definitions by guarding them with
> +BUILDING_CHROMIUM which we define when compiling QtWebEngineCore.
> +
> +Change-Id: I33719c08300211f4ad304efa3e7a5326136bb3cf
> +Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com>
> +---
> + chromium/third_party/mesa/src/include/GL/glext.h | 2 ++
> + 1 file changed, 2 insertions(+)
> +
> +diff --git a/chromium/third_party/mesa/src/include/GL/glext.h b/chromium/third_party/mesa/src/include/GL/glext.h
> +index cb19ed4..1b78767 100644
> +--- a/chromium/third_party/mesa/src/include/GL/glext.h
> ++++ b/chromium/third_party/mesa/src/include/GL/glext.h
> +@@ -6148,6 +6148,7 @@ typedef char GLchar;
> + #endif
> + 
> + #ifndef GL_VERSION_1_5
> ++#ifndef BUILDING_CHROMIUM
> + /* GL types for handling large vertex buffer objects */
> + #ifdef _WIN64
> + typedef signed   long long int GLintptr;
> +@@ -6157,6 +6158,7 @@ typedef signed   long  int     GLintptr;
> + typedef signed   long  int     GLsizeiptr;
> + #endif
> + #endif
> ++#endif
> + 
> + #ifndef GL_ARB_vertex_buffer_object
> + /* GL types for handling large vertex buffer objects */
> +-- 
> +cgit v0.11.0
> +

Bah, this is a terrible so-called "fix" from upstream.  It leaves sane
distros that use the system Mesa library to develop their own fix, since
they apparently can't be bothered to fix it properly :-(

> I should have taken a closer look; this patches the in-tree Mesa
> headers, which are of course not used when building with system Mesa.
> 
> I will investigate further but don't hold your breath.  Although in
> worst case we could build with Qt's in-tree copy of Mesa.

Please, let's not do that.  We should be moving in the other direction,
by using less, not more, of the unbelievably massive amount of bundled
stuff in Qt.

If this "fix" is the really best we can hope for from upstream, then
let's do it this way instead: after unpacking Qt 5, make a copy of
glext.h from *our* system Mesa, apply the above patch to that copy, and
arrange for that patched copy to be found first in the include search
path during the Qt build.  Then at least we will have only one copy of
Mesa in memory and only one copy of the Mesa source code to maintain
(for security fixes, fixes for non-Intel platforms, fixes for Guix,
etc).

Thanks again, Taylan, for working on this unpleasant task.

     Mark

Re: [PATCH] Patch Qt 5.4 for i686.

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Please, let's not do that.  We should be moving in the other direction,
> by using less, not more, of the unbelievably massive amount of bundled
> stuff in Qt.

Agreed.

> If this "fix" is the really best we can hope for from upstream, then
> let's do it this way instead: after unpacking Qt 5, make a copy of
> glext.h from *our* system Mesa, apply the above patch to that copy, and
> arrange for that patched copy to be found first in the include search
> path during the Qt build.  Then at least we will have only one copy of
> Mesa in memory and only one copy of the Mesa source code to maintain
> (for security fixes, fixes for non-Intel platforms, fixes for Guix,
> etc).

Sounds like a good plan.

> Thanks again, Taylan, for working on this unpleasant task.

Indeed, this is neither easy nor funny, but work in this area is
definitely appreciated!

Thanks,
Ludo’.

Re: [PATCH] Patch Qt 5.4 for i686.

[Taylan Ulrich Bayırlı/Kammer]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Please, let's not do that.  We should be moving in the other direction,
>> by using less, not more, of the unbelievably massive amount of bundled
>> stuff in Qt.
>
> Agreed.
>
>> If this "fix" is the really best we can hope for from upstream, then
>> let's do it this way instead: after unpacking Qt 5, make a copy of
>> glext.h from *our* system Mesa, apply the above patch to that copy, and
>> arrange for that patched copy to be found first in the include search
>> path during the Qt build.  Then at least we will have only one copy of
>> Mesa in memory and only one copy of the Mesa source code to maintain
>> (for security fixes, fixes for non-Intel platforms, fixes for Guix,
>> etc).
>
> Sounds like a good plan.
>
>> Thanks again, Taylan, for working on this unpleasant task.
>
> Indeed, this is neither easy nor funny, but work in this area is
> definitely appreciated!
>
> Thanks,
> Ludo’.

Seems I left this thread dangling; I sent a new patch in a new thread on
the meanwhile.  And it even seems to work this time. :-)

Taylan