https://bugs.winehq.org/show_bug.cgi?id=56973
Bug ID: 56973 Summary: Building wine with mingw/gcc 14.1.1 fails with error '-Wimplicit-function-declaration' Product: Wine Version: 9.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs@winehq.org Reporter: arusanu.bu@gmail.com Distribution: ---
After updating mingw/gcc to 14.1.0 wine fails to build with error:
< i686-w64-mingw32-gcc -c -o dlls/msxml3/i386-windows/domdoc.o dlls/msxml3/domdoc.c -Idlls/msxml3 -Iinclude -Iinclude/msvcrt \ -I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2 -D_UCRT -D__WINESRC__ -D__WINE_PE_BUILD \ -Wall -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Winit-self -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -Wabsolute-value \ -Wenum-conversion -Wno-misleading-indentation -fno-omit-frame-pointer -mpreferred-stack-boundary=2 \ -gdwarf-4 -g -O2 dlls/msxml3/domdoc.c: In function 'doparse': dlls/msxml3/domdoc.c:546:9: error: initialization of 'void (*)(void *, const xmlError *)' {aka 'void (*)(void *, const struct _xmlError *)'} from incompatible pointer type 'void (*)(void *, xmlError *)' {aka 'void (*)(void *, struct _xmlError *)'} [-Wincompatible-pointer-types] 546 | sax_serror /* serror */ | ^~~~~~~~~~ dlls/msxml3/domdoc.c:546:9: note: (near initialization for 'sax_handler.serror') make: *** [Makefile:78873: dlls/msxml3/i386-windows/domdoc.o] Error 1 >
Adding "-Wno-error=incompatible-pointer-types" to CROSSCFLAGS seems to circumvent this error but run into the following error:
<i686-w64-mingw32-gcc -c -o dlls/msxml3/i386-windows/main.o dlls/msxml3/main.c -Idlls/msxml3 -Iinclude -Iinclude/msvcrt \ -I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2 -D_UCRT -D__WINESRC__ -D__WINE_PE_BUILD \ -Wall -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Winit-self -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -Wabsolute-value \ -Wenum-conversion -Wno-misleading-indentation -fno-omit-frame-pointer -mpreferred-stack-boundary=2 \ -Wno-error=incompatible-pointer-types dlls/msxml3/main.c: In function 'DllMain': dlls/msxml3/main.c:360:9: error: implicit declaration of function 'xmlThrDefTreeIndentString'; did you mean 'xmlTreeIndentString'? [-Wimplicit-function-declaration] 360 | xmlThrDefTreeIndentString("\t"); | ^~~~~~~~~~~~~~~~~~~~~~~~~ | xmlTreeIndentString make: *** [Makefile:79085: dlls/msxml3/i386-windows/main.o] Error 1 >
which have been mitigated by adding "-Wno-error=-Wimplicit-function-declaration", and that allowed wine to build successfully.
This doesn't happen using mingw/gcc 13.2 or 12.2
If any other details/tests requests are needed will gladly provide.
https://bugs.winehq.org/show_bug.cgi?id=56973
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- I think the question here is why this path is used:
-I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2
It's most likely incompatible, and for wine we are using imported libxml2 code, including headers.
Current prototype is:
static void sax_serror(void* ctx, xmlErrorPtr err)
and from libs/xml2 the type is:
typedef void (*xmlStructuredErrorFunc) (void *userData, xmlErrorPtr error);
So it should work fine together.
https://bugs.winehq.org/show_bug.cgi?id=56973
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #2 from Zeb Figura z.figura12@gmail.com --- (In reply to Nikolay Sivov from comment #1)
I think the question here is why this path is used:
-I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2
It's most likely incompatible, and for wine we are using imported libxml2 code, including headers.
Because using external PE libraries is supported. Are we modifying the bundled libxml in a way that makes it incompatible? If so (and assuming we really do need to do that) we shouldn't allow using external libxml.
https://bugs.winehq.org/show_bug.cgi?id=56973
--- Comment #3 from aurb arusanu.bu@gmail.com --- (In reply to Nikolay Sivov from comment #1)
I think the question here is why this path is used:
You are spot on and I'm sorry for my ignorance and wasting your time. I have a little patch that enabled wine to be build against some system mingw libraries, among them the "xml2", once wine used its bundled libraries everything went back to normal. Again, really sorry, I would close this as invalid.
https://bugs.winehq.org/show_bug.cgi?id=56973
--- Comment #4 from aurb arusanu.bu@gmail.com --- (In reply to Zeb Figura from comment #2)
-I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2
It's most likely incompatible, and for wine we are using imported libxml2 code, including headers.
Because using external PE libraries is supported. Are we modifying the bundled libxml in a way that makes it incompatible? If so (and assuming we really do need to do that) we shouldn't allow using external libxml.
Until now I've been using system build mingw libraries for: FAudio, lcms2, libpng, libxml2, libxslt, vkd3d, vulkan-headers, zlib, libjpeg-turbo, libtiff, fluidsynth, gsm, mpg123, where most of them are quite recent releases or at least the same version as wine bundled ones.
1. The issue showed up only after migwn was build with gcc-14.1 and some of these mingw libraries have not been yet build against new mingw-gcc, I would look into it.
2. Anyhow, my workaround from original comment had some regressions too. One game crashed while it works fine if wine is build with bundled libraries.
https://bugs.winehq.org/show_bug.cgi?id=56973
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Zeb Figura from comment #2)
(In reply to Nikolay Sivov from comment #1)
I think the question here is why this path is used:
-I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2
It's most likely incompatible, and for wine we are using imported libxml2 code, including headers.
Because using external PE libraries is supported. Are we modifying the bundled libxml in a way that makes it incompatible? If so (and assuming we really do need to do that) we shouldn't allow using external libxml.
No, we don't modify it. It appears to be their change [1], for no good reason.
[1] https://gitlab.gnome.org/GNOME/libxml2/-/commit/61034116d
https://bugs.winehq.org/show_bug.cgi?id=56973
--- Comment #6 from aurb arusanu.bu@gmail.com --- (In reply to Nikolay Sivov from comment #5)
No, we don't modify it. It appears to be their change [1], for no good reason.
[1] https://gitlab.gnome.org/GNOME/libxml2/-/commit/61034116d
Tested against libxml2-2.11.8, the version before the commit you found, and that works fine with gcc-14.1. There is no actual need to rebuild the other system mingw libraries or at least no issues/regressions popped up in my limited tests.
For the moment I will stick with bundled versions of the xml2/xslt; Thanks.
PS; I'm not sure if this bug should be closed, as it looks like a decision has to be made at some point.
https://bugs.winehq.org/show_bug.cgi?id=56973
aurb arusanu.bu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #7 from aurb arusanu.bu@gmail.com --- This bug seems to be fixed by commit - https://gitlab.winehq.org/wine/wine/-/commit/9d34c44d8464722c333fdde5313b341... . I'm currently successfully building wine against system's mingw-libxml2, version 2.12.9, and there is no noticeable regression for my use case. Consider this issue solved, :). Thank you.
https://bugs.winehq.org/show_bug.cgi?id=56973
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.20.