Created attachment 223635 [details] wine 5.0.4,1 build error Build fails on 13.0-RC3 with the following options: ---Begin OPTIONS List--- ===> The following configuration options are available for wine-5.0.4,1: CUPS=on: CUPS printing system support DOCS=on: Build and/or install documentation DOSBOX=off: Use DOSBox to run MS-DOS programs GECKO=off: Bundle Gecko MSI package for Wine GNUTLS=on: SSL/TLS support via GnuTLS LDAP=off: LDAP protocol support LIBXSLT=on: Use libxslt (only used by msxml3.dll) MONO=off: Bundle Mono MSI package for Wine MPG123=on: MP3 decoding support via mpg123 OPENAL=off: Audio support via OpenAL SDL=off: Use SDL for gamepad support (XInput only) V4L=off: Video 4 Linux support VKD3D=off: Direct3D 12 support via Vulkan VULKAN=off: Vulkan API support WINEMAKER=off: Fully support winemaker (requires Perl) X11=on: X11 (graphics) support ===> Use 'make config' to modify these settings ---End OPTIONS List--- DEFAULT_VERSIONS+= ssl=libressl samba=4.13 Build error attached, full log is here: http://home.palmen-it.de/builder/data/def-default/2021-03-27_11h46m13s/logs/errors/wine-5.0.4,1.log
Is this a regression for you? That is, can you build version 5.0.3 with exactly the same options in exactly the same environment? I'm a bit puzzled that this appears in a context related to V4l, when it seems you do have the V4L option off. (Do you have V4L packages installed?) I have not yet received any report from the automated builders, which usually is an indication that something must be special in your environment. Any ideas what that might be?
Yes, it is a regression, for reference, here's the log of the successful build for 5.0.3: http://home.palmen-it.de/builder/data/latest-per-pkg/wine/5.0.3_1%2C1/def-default.log As this is a poudriere build, you can see in the logs what is installed (only what the port requests as dependencies), and I can't spot anything related to V4L there. About what's special, that's probably my port options (I think CUPS, LIBXSLT, and MPEG123 aren't enabled by default). I also have DEFAULT_VERSIONS+=ssl=libressl, but don't think that could be related.
Created attachment 223642 [details] fix missing declaration of debug channel in dlls/qcap/v4l.c I now analyzed this myself, it looks like it's an upstream error. I don't know why dlls/qcap/v4l.c is compiled in my configuration, but it does have #ifdefs for conditional compilation of code depending on v4l. The declaration of the default debug channel was moved inside such an #ifdef, causing the build error. For comparison, see the code from 5.0.3 here: https://source.winehq.org/git/wine.git/blob/69859b4174119c0eb5f48aa0fa54710eca1ee25c:/dlls/qcap/v4l.c#l66 The attached patch restores the declaration outside the #ifdef. It fixes the build for me…
(In reply to Felix Palmen from comment #2) > As this is a poudriere build, you can see in the logs what is installed > (only what the port requests as dependencies), and I can't spot anything > related to V4L there. Thank you, Felix. Indeed I had missed that part of the log at first, which was simply my mistake. I could only spend a bit of time digging into this today, so all the more appreciate your proposed patch. It turns out there are two issues at work here: the one you are reporting (which affects most users) and another one that hid this during my own tests. I'll tackle the first one for us (FreeBSD Ports Collection) first, and then also upstream, and will also look into the other one.
(In reply to Gerald Pfeifer from comment #4) > another one that hid this during my own tests. I didn't do complete testing either, but looking at the issue I found, it's very likely that you can only run into this problem with an option enabled that causes the dlls/qcap dir to be built (maybe it's MPG123 in my case?), BUT enabling V4L at the same time will hide the problem again, because (behind the #ifdef) the required declaration would be there. So, the only way to reliable find this with build tests would be to test any possible *combination* of options. > I'll tackle the first one for us (FreeBSD Ports Collection) first, and then > also upstream Thanks! Taking this upstream sounds reasonable, doesn't look like a FreeBSD-specific issue.
A commit references this bug: Author: gerald Date: Mon Mar 29 22:50:27 UTC 2021 New revision: 569523 URL: https://svnweb.freebsd.org/changeset/ports/569523 Log: The update to Wine 5.0.4 brought a potential build problem depending on options chosen and packages installed (or not). Temporarily add a patch files/patch-dlls_qcap_v4l.c to resolve problems where v4l (multimedia/libv4l) is used when present, even if explicitly disabled during ./configure. PR: 254601 Submitted by: Felix Palmen <felix@palmen-it.de> Changes: head/emulators/wine/files/patch-dlls_qcap_v4l.c
Just a remark: I don't think it attempts to use v4l, cause most code in dlls/qcap/v4l.c is guarded by #ifdefs. My guess is that several build/configure options (including but not limited to --with-v4l2) lead to dlls/qcap being compiled, and then it fails when v4l is NOT used, because a debug channel that's declared behind an #ifdef is still referenced. Maybe this theory could help with a quick resolution upstream. Thanks for committing the patch!
Hi Felix, I dug into this a bit and reported the issue with a bit more of an analysis upstream: https://www.winehq.org/pipermail/wine-devel/2021-March/183900.html One of the contributors confirmed: https://www.winehq.org/pipermail/wine-devel/2021-March/183943.html The maintainer of 5.0 release branch reverted the problematic patch, and a Wine 5.0.5 release should address this: https://www.winehq.org/pipermail/wine-devel/2021-March/183960.html Thanks for your fine report and analysis!