On 09/03/17 07:30, Marek Olšák wrote:
On Wed, Mar 8, 2017 at 9:14 PM, Vinson Lee <v...@freedesktop.org> wrote:
On Sat, Mar 4, 2017 at 3:42 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
On 4 March 2017 at 22:43, Vinson Lee <v...@freedesktop.org> wrote:
On Sat, Mar 4, 2017 at 5:24 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
On 4 March 2017 at 22:13, Vinson Lee <v...@freedesktop.org> wrote:
Fixes: 85a9b1b562b6 ("util/disk_cache: compress individual cache entries")
Signed-off-by: Vinson Lee <v...@freedesktop.org>
---
configure.ac | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 943bc05adcd6..3526849b6dd2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -786,7 +786,7 @@ dnl See if posix_memalign is available
AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
dnl Check for zlib
-PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
+PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED], [DEFINES="$DEFINES
-DENABLE_SHADER_CACHE"], [:])
Why - is it causing breakage or any system ?
Afaict we really want to have this tested thoroughly and silently
disabling it is a very bad idea.
-Emil
Older distros have a zlib older than 1.2.8.
Tim I think you had something in mind about such cases, hehe ;-)
But seriously, seems like enterprise Linuxes are stuck with very old ones:
RHEL4 - 1.2.1
RHEL 5/6 - 1.2.3
SLES 10/11 - 1.2.3
Tim, I'll leave the rest to you - how/worth using third party package,
dropping to 1.2.3 or other ?
I'm leaning towards 1.2.3, unless there's some serious down sides with it.
-Emil
Is downgrading to zlib 1.2.3 okay? Otherwise, can we add support to
not build the shader cache in the autoconf build?
Users building from source can build zlib from source too. I don't see
a problem with that. If we wanna make it easier for them, we can allow
zlib 1.2.3 as well. In any case, the shader cache should remain
enabled.
Marek
I made a comment about 1.2.3 support in the bug report [1]. IMO we
should not be setting lib requirements to versions that have not seen
regular testing with Mesa, and in the process exposing us to a larger
range of potential versions to test against should a bug appear. Also I
think it's outside of our responsibility to worry about distros using
heavily patched very out of date libraries.
For example RHEL 6 ships 1.2.3-28, this get's us into a situation where
we are not really recommending 1.2.3 but the heavily patches variants
shipped in these distros. I already think we are are doing the wrong
thing by setting GCC at 4.2.0 (for BSD's forked GCC variant) I'd rather
not start doing it for other software.
For what it's worth I know for a fact that Firefox does not support the
out of date GTK versions shipped with RHEL 6 and Redhat needs to keep
their own patches to keep things working on these GTK versions (among
the many other issues they face).
So as much as I appreciate the testing done by Vinson and don't want to
make things too difficult, I believe the correct solution would be that
anyone building on RHEL 6 carry their own patch to downgrade to 1.2.3.
Tim
[1] https://bugs.freedesktop.org/show_bug.cgi?id=100093
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
