Not quite sure how wine is even involved in a mingw cross-build (except that I do use it for *running* the tests, but it doesn't get that far because they don't build). But last week, from one build to the next, the mingw builds of OpenConnect in CI just stopped working thus: ./.libs/lt-bad_dtls_test.c:165:33: warning: missing terminating " character 165 | const char * EXE_PATH_VALUE = "Z:\\usr\\i686-w64-mingw32\\sys-root\\mingw\\lib ;Z:\\usr\\i686-w64-mingw32\\sys-root\\mingw\\bin ;"; | ^ There are actually CR characters in that string, before each semicolon. Last working build: https://gitlab.com/openconnect/openconnect/-/jobs/522413511 First failing build, only a few minutes later. https://gitlab.com/openconnect/openconnect/-/jobs/523380153 Comparing the builds, the *only* difference in the environment is that the failing one has wine 5.6 while the working one has wine 5.5. I can reproduce this on Fedora 31 by just cloning the openconnect git tree and building it with mingw.
This could well be a libtool problem, as those files are generated by libtool.
Downgrading wine to 4.17 (since dnf wouldn't give me 5.5) fixes it on my Fedora 31 system. Remove wine, and it still works fine. Install wine 5.6 again, and it breaks again. Removing just the 'wine' package and/or disabling binfmt_misc doesn't fix it. Removing wine-common makes it spit out this warning: libtool: error: Could not determine the host path corresponding to libtool: error: '/home/dwmw2/openconnect/.libs' libtool: error: Continuing, but uninstalled executables may not work. libtool: error: Could not determine the host path corresponding to libtool: error: '/usr/x86_64-w64-mingw32/sys-root/mingw/lib:/usr/x86_64-w64-mingw32/sys-root/mingw/bin:/home/dwmw2/openconnect/.libs' libtool: error: Continuing, but uninstalled executables may not work. ... but it does actually build.
Aha, it's "winepath", which started emitting Windows line endings that libtool doesn't expect. With wine 5.6: $ winepath -w . | hexdump -C 00000000 5a 3a 5c 68 6f 6d 65 5c 64 77 6d 77 32 5c 6f 70 |Z:\home\dwmw2\op| 00000010 65 6e 63 6f 6e 6e 65 63 74 5c 2e 0d 0a |enconnect\...| 0000001d With 5.0: $ winepath -w . | hexdump -C 00000000 5a 3a 5c 68 6f 6d 65 5c 64 77 6d 77 32 5c 6f 70 |Z:\home\dwmw2\op| 00000010 65 6e 63 6f 6e 6e 65 63 74 5c 2e 0a |enconnect\..| 0000001c
Thanks for the info, David. I'm trying to get wine-mono 5.0.0 built in order to get wine 5.7 pushed.
FEDORA-2020-bd25c9ee79 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-bd25c9ee79
FEDORA-2020-1ab58b829d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1ab58b829d
FEDORA-2020-bd25c9ee79 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-bd25c9ee79` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bd25c9ee79 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-1ab58b829d has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1ab58b829d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1ab58b829d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-bd25c9ee79 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-1ab58b829d has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.