guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Patch Qt 5.4 for i686.


From: Mark H Weaver
Subject: Re: [PATCH] Patch Qt 5.4 for i686.
Date: Sat, 25 Apr 2015 01:17:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hi Taylan,

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

address@hidden (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?=
>  <address@hidden>
> 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 <address@hidden>
> +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 <address@hidden>
> +---
> + 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]