[Buildroot] [PATCH 1/1] mpv: disable static build with qt-zlib

[Buildroot] [PATCH 1/1] mpv: disable static build with qt-zlib

[Fabrice Fontaine]

Static build of mpv with qt-zlib will fail because zlib and qt-zlib
defines the same functions (inflateReset, inflatePrime ...)

So add a dependency on !(BR2_STATIC_LIBS && BR2_PACKAGE_QT_QTZLIB)

Theoretically, this dependency should be put on zlib package on all its
reverse dependencies but this make a lot of packages

Fixes:
 - http://autobuild.buildroot.org/results/0be6e359d46a8a701006305c32b514687854b035

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 package/mpv/Config.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/mpv/Config.in b/package/mpv/Config.in
index 69810038f1..a2b023868a 100644
--- a/package/mpv/Config.in
+++ b/package/mpv/Config.in
@@ -4,6 +4,7 @@ config BR2_PACKAGE_MPV
 	depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
 	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_5
 	depends on BR2_TOOLCHAIN_HAS_ATOMIC || BR2_TOOLCHAIN_HAS_SYNC_8
+	depends on !(BR2_STATIC_LIBS && BR2_PACKAGE_QT_QTZLIB)
 	select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
 	select BR2_PACKAGE_FFMPEG
 	select BR2_PACKAGE_FFMPEG_SWSCALE
@@ -25,5 +26,6 @@ config BR2_PACKAGE_MPV
 comment "mpv needs a toolchain w/ threads, gcc >= 4.5"
 	depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
 	depends on BR2_TOOLCHAIN_HAS_ATOMIC || BR2_TOOLCHAIN_HAS_SYNC_8
+	depends on !(BR2_STATIC_LIBS && BR2_PACKAGE_QT_QTZLIB)
 	depends on !BR2_TOOLCHAIN_HAS_THREADS || \
 		!BR2_TOOLCHAIN_GCC_AT_LEAST_4_5
-- 
2.17.1

[Buildroot] [PATCH 1/1] mpv: disable static build with qt-zlib

[Thomas Petazzoni]

Hello Fabrice,

On Fri,  2 Nov 2018 19:24:16 +0100, Fabrice Fontaine wrote:
> Static build of mpv with qt-zlib will fail because zlib and qt-zlib
> defines the same functions (inflateReset, inflatePrime ...)
> 
> So add a dependency on !(BR2_STATIC_LIBS && BR2_PACKAGE_QT_QTZLIB)
> 
> Theoretically, this dependency should be put on zlib package on all its
> reverse dependencies but this make a lot of packages

Why? zlib doesn't have any problem at all.

I don't think this patch is the right solution. First, because the
problem is in Qt, not in MPV. Fixing it at the MPV level means that all
other packages that use Qt may still be affected by the same issue.

I believe the problem comes the fact that Qt can use Zlib in two modes:
with a built-in zlib copy (BR2_PACKAGE_QT_QTZLIB) and with the system
zlib (BR2_PACKAGE_QT_SYSTEMZLIB). Because those options are part of a
choice, and choices are not randomized by the autobuilder
infrastructure, only BR2_PACKAGE_QT_QTZLIB gets tested and
BR2_PACKAGE_QT_SYSTEMZLIB is never tested.

I believe that with BR2_PACKAGE_QT_SYSTEMZLIB, the static build should
work, because there is only one copy of the zlib functions, in libz.a.
The problem with BR2_PACKAGE_QT_QTZLIB is that you end up with two
copies of all zlib functions: one in libz.a and one in libQtCore.a.

It would be great if you could confirm that the same configuration
builds properly when BR2_PACKAGE_QT_SYSTEMZLIB is used instead of
BR2_PACKAGE_QT_QTZLIB. If that is the case, then I believe the right
fix is to add a depends on !BR2_STATIC_LIBS to the
BR2_PACKAGE_QT_QTZLIB option.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] mpv: disable static build with qt-zlib

[Arnout Vandecappelle]

On 03/11/18 14:26, Thomas Petazzoni wrote:
[snip]
> It would be great if you could confirm that the same configuration
> builds properly when BR2_PACKAGE_QT_SYSTEMZLIB is used instead of
> BR2_PACKAGE_QT_QTZLIB. If that is the case, then I believe the right
> fix is to add a depends on !BR2_STATIC_LIBS to the
> BR2_PACKAGE_QT_QTZLIB option.

 Or maybe remove the QTZLIB option entirely.

 (Or maybe remove qt4 entirely :-)

 Regards,
 Arnout

[Buildroot] [PATCH 1/1] mpv: disable static build with qt-zlib

[Thomas Petazzoni]

Hello,

On Sat, 3 Nov 2018 23:15:00 +0100, Arnout Vandecappelle wrote:

>  Or maybe remove the QTZLIB option entirely.

Yeah, true. I'm not sure what is the motivation for using the
non-system zlib variant.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com