Having problems (re-)building i686 wine staging rpm's on fedora
Due to having a few modifications considered unsuitable for upstreaming, I have been grabbing the official fedora rpm's since at least wine-1.9.20 / 2016 , patching the spec file, adding my patches, plus a "Epoch: 100" line, so it blocks auto--upgrades, until I rebuild it myself every two or three wine releases. This has worked well for 6+ years, until 7.3+ . I last built 7.2 staging with (rpmbuild -bb wine.spec && rpmbuild --target=i686 -bb wine.spec) 2>&1 | tee build-log . Fedora's koji build farm only have 7.3, 7.5, 7.9, and 7.10. I tried 7.10 and the x86_64 part finished (*see notes below), but the i686 part just wouldn't go ahead, due to some PE-related collisions. I back-tracked, and found the failure was between 7.3 and 7.5. === i686-w64-mingw32-gcc -c -o dlls/windowscodecs/libjpeg.cross.o dlls/windowscodecs/libjpeg.c -Idlls/windowscodecs -Iinclude -Iinclude/msvcrt \ -I/usr/include -I./libs/png -D__WINESRC__ -D_UCRT -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 \ -fno-omit-frame-pointer -gdwarf-4 -g -O2 In file included from include/objbase.h:20, from dlls/windowscodecs/libjpeg.c:31: include/rpcndr.h:73:23: error: conflicting types for 'boolean'; have 'unsigned char' 73 | typedef unsigned char boolean; | ^~~~~~~ In file included from /usr/include/jpeglib.h:31, from dlls/windowscodecs/libjpeg.c:24: /usr/include/jmorecfg.h:207:13: note: previous declaration of 'boolean' with type 'boolean' {aka 'int'} 207 | typedef int boolean; | ^~~~~~~ dlls/windowscodecs/libjpeg.c: In function 'jpeg_decoder_initialize': dlls/windowscodecs/libjpeg.c:180:40: warning: assignment to 'boolean (*)(struct jpeg_decompress_struct *)' {aka 'int (*)(struct jpeg_decompress_struct *)'} from incompatible pointer type 'boolean (*)(struct jpeg_decompress_struct *)' {aka 'unsigned char (*)(struct jpeg_decompress_struct *)'} [-Wincompatible-pointer-types] 180 | This->source_mgr.fill_input_buffer = source_mgr_fill_input_buffer; | ^ dlls/windowscodecs/libjpeg.c: In function 'jpeg_encoder_initialize': dlls/windowscodecs/libjpeg.c:466:40: warning: assignment to 'boolean (*)(struct jpeg_compress_struct *)' {aka 'int (*)(struct jpeg_compress_struct *)'} from incompatible pointer type 'boolean (*)(struct jpeg_compress_struct *)' {aka 'unsigned char (*)(struct jpeg_compress_struct *)'} [-Wincompatible-pointer-types] 466 | This->dest_mgr.empty_output_buffer = dest_mgr_empty_output_buffer; | ^ make: *** [Makefile:127914: dlls/windowscodecs/libjpeg.cross.o] Error 1 === I tried setting PNG_PE_CFLAGS, ZLIB_PE_CFLAGS, LCMS2_PE_CFLAGS, JPEG_PE_CFLAGS, JPEG_PE_LIBS etc explicitly, and sometimes it get worse. Anyway, I have tried some many things that I thought it might be worth reaching out to the people who maintain the fedora rpm's as well as well wine-devel. A few questions/thoughts: - it seems that the build system is getting confused occasionally about say, native headers vs mingw headers like jpeg-devel; at some point, I got a error saying I was trying to build one of the unixlib.c's with mingw headers, for example. But I see for example that in the generated Makefile for dlls/windowscodecs/ , It is feeding *PE_FLAGS to unixlib.c (plus the PE stub), and I explicitly put -I...mingw32/include to *PE_FLAGS. That seems wrong. - I don't understand why --target=x86_64 rebuild works, built --target=i686 rebuild fails with the above error. My list of mingw32-* packages and mingw64-* packages are almost identical, I think, and certainly regarding libjpeg (zlib/png dependencies) . I have the 29MB combined x86-64 and i686 build-log of 7.3, plus the 15MB x86-64 and ~3MB i686 failure of each of 7.5/7.9/7.10 ; but it is kind of difficult to see what to check. Any hints on what to look at at config.log would be useful. *note rpmbuild detects isdn4k-utils on my system so I needed to add these two lines +%{_libdir}/wine/%{winesodir}/capi2032.so +%{_libdir}/wine/%{winepedir}/capi2032.dll to my modified spec. I suppose I should formalize this part of my diff with one furthe line of BuildRequires: isdn4k-utils-devel as a reminder to myself.
Hello Hin-Tak, On 6/11/22 18:35, Hin-Tak Leung wrote:
i686-w64-mingw32-gcc -c -o dlls/windowscodecs/libjpeg.cross.o dlls/windowscodecs/libjpeg.c -Idlls/windowscodecs -Iinclude -Iinclude/msvcrt \ -I/usr/include -I./libs/png -D__WINESRC__ -D_UCRT -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 \ -fno-omit-frame-pointer -gdwarf-4 -g -O2 In file included from include/objbase.h:20, from dlls/windowscodecs/libjpeg.c:31: include/rpcndr.h:73:23: error: conflicting types for 'boolean'; have 'unsigned char' 73 | typedef unsigned char boolean; | ^~~~~~~ In file included from /usr/include/jpeglib.h:31, from dlls/windowscodecs/libjpeg.c:24: /usr/include/jmorecfg.h:207:13: note: previous declaration of 'boolean' with type 'boolean' {aka 'int'} 207 | typedef int boolean; | ^~~~~~~ dlls/windowscodecs/libjpeg.c: In function 'jpeg_decoder_initialize': This should be prevented by HAVE_BOOLEAN, defined in jconfig.h for win32 targets. It seems that the host libjpeg headers are being included instead.
I have some guesses as to how this happened, but I'm not fully sure. Can you please attach your config.log?
A few questions/thoughts:
- it seems that the build system is getting confused occasionally about say, native headers vs mingw headers like jpeg-devel; at some point, I got a error saying I was trying to build one of the unixlib.c's with mingw headers, for example. But I see for example that in the generated Makefile for dlls/windowscodecs/ , It is feeding *PE_FLAGS to unixlib.c (plus the PE stub), and I explicitly put -I...mingw32/include to *PE_FLAGS. That seems wrong.
There's no unixlib.c in windowscodecs. Are you referring to a different DLL? What error did you get?
I downloaded the official fedora build log from koji, fedora's build farm, and compared it with mine, and found the answer: I needed to do "dnf erase mingw32-libtiff mingw32-libjpeg-turbo". It seems that the present of the causes wine's build system to assume mingw32 libtiff and mingw32 libjpeg are present, but they are actually not useable on fedora. However I don't understand why the mingw64* packages don't cause problems... Hmm, maybe I do, wine doesn't use the mingw64 packages as much - it is not symmetrical, win32 and wow64 is not symmetrical. brief investigation seems to suggest the mingw32-pkg-config values from those are a bit funny. But I think it is a job for the fedora wine maintainers to try to get the fedora mingw32 packages to build nice with wine... # grep 'not found' kojipkgs.fedoraproject.org/packages/wine/7.10/2.fc36/data/logs/x86_64/build.log checking for -lnetapi... not found configure: FAudio 64-bit MinGW development files not found (or too old); using bundled version. configure: libjpeg 64-bit MinGW development files not found; using bundled version. configure: libmpg123 64-bit MinGW development files not found (or too old); using bundled version. configure: libtiff 64-bit MinGW development files not found; using bundled version. configure: libvkd3d 64-bit MinGW development files not found; using bundled version. configure: libcapi20 64-bit development files not found, ISDN won't be supported. configure: libnetapi not found, Samba NetAPI won't be supported. # grep 'not found' kojipkgs.fedoraproject.org/packages/wine/7.10/2.fc36/data/logs/i686/build.log checking for -lnetapi... not found configure: FAudio MinGW development files not found (or too old); using bundled version. configure: libjpeg MinGW development files not found; using bundled version. configure: libmpg123 MinGW development files not found (or too old); using bundled version. configure: libtiff MinGW development files not found; using bundled version. configure: libvkd3d MinGW development files not found; using bundled version. configure: libcapi20 development files not found, ISDN won't be supported. configure: libnetapi not found, Samba NetAPI won't be supported. mine have somewhat fewer 'not found'. In particular, I have the libcapi20 dev files so I have the ISDN support. # grep 'not found' mine/wine-7.10.spec.diff-log checking for -lnetapi... not found configure: FAudio 64-bit MinGW development files not found (or too old); using bundled version. configure: libmpg123 64-bit MinGW development files not found (or too old); using bundled version. configure: libvkd3d 64-bit MinGW development files not found; using bundled version. configure: libnetapi not found, Samba NetAPI won't be supported. # grep 'not found' mine/wine-7.10.spec.diff-log-4 checking for -lnetapi... not found configure: FAudio 32-bit MinGW development files not found (or too old); using bundled version. configure: liblcms2 32-bit MinGW development files not found; using bundled version. configure: libmpg123 32-bit MinGW development files not found (or too old); using bundled version. configure: libpng 32-bit MinGW development files not found; using bundled version. configure: libvkd3d 32-bit MinGW development files not found; using bundled version. configure: zlib 32-bit MinGW development files not found; using bundled version. configure: libnetapi not found, Samba NetAPI won't be supported. On Sunday, 12 June 2022, 00:35:22 BST, Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote: Due to having a few modifications considered unsuitable for upstreaming, I have been grabbing the official fedora rpm's since at least wine-1.9.20 / 2016 , patching the spec file, adding my patches, plus a "Epoch: 100" line, so it blocks auto--upgrades, until I rebuild it myself every two or three wine releases. This has worked well for 6+ years, until 7.3+ . I last built 7.2 staging with (rpmbuild -bb wine.spec && rpmbuild --target=i686 -bb wine.spec) 2>&1 | tee build-log . Fedora's koji build farm only have 7.3, 7.5, 7.9, and 7.10. I tried 7.10 and the x86_64 part finished (*see notes below), but the i686 part just wouldn't go ahead, due to some PE-related collisions. I back-tracked, and found the failure was between 7.3 and 7.5. === i686-w64-mingw32-gcc -c -o dlls/windowscodecs/libjpeg.cross.o dlls/windowscodecs/libjpeg.c -Idlls/windowscodecs -Iinclude -Iinclude/msvcrt \ -I/usr/include -I./libs/png -D__WINESRC__ -D_UCRT -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 \ -fno-omit-frame-pointer -gdwarf-4 -g -O2 In file included from include/objbase.h:20, from dlls/windowscodecs/libjpeg.c:31: include/rpcndr.h:73:23: error: conflicting types for 'boolean'; have 'unsigned char' 73 | typedef unsigned char boolean; | ^~~~~~~ In file included from /usr/include/jpeglib.h:31, from dlls/windowscodecs/libjpeg.c:24: /usr/include/jmorecfg.h:207:13: note: previous declaration of 'boolean' with type 'boolean' {aka 'int'} 207 | typedef int boolean; | ^~~~~~~ dlls/windowscodecs/libjpeg.c: In function 'jpeg_decoder_initialize': dlls/windowscodecs/libjpeg.c:180:40: warning: assignment to 'boolean (*)(struct jpeg_decompress_struct *)' {aka 'int (*)(struct jpeg_decompress_struct *)'} from incompatible pointer type 'boolean (*)(struct jpeg_decompress_struct *)' {aka 'unsigned char (*)(struct jpeg_decompress_struct *)'} [-Wincompatible-pointer-types] 180 | This->source_mgr.fill_input_buffer = source_mgr_fill_input_buffer; | ^ dlls/windowscodecs/libjpeg.c: In function 'jpeg_encoder_initialize': dlls/windowscodecs/libjpeg.c:466:40: warning: assignment to 'boolean (*)(struct jpeg_compress_struct *)' {aka 'int (*)(struct jpeg_compress_struct *)'} from incompatible pointer type 'boolean (*)(struct jpeg_compress_struct *)' {aka 'unsigned char (*)(struct jpeg_compress_struct *)'} [-Wincompatible-pointer-types] 466 | This->dest_mgr.empty_output_buffer = dest_mgr_empty_output_buffer; | ^ make: *** [Makefile:127914: dlls/windowscodecs/libjpeg.cross.o] Error 1 === I tried setting PNG_PE_CFLAGS, ZLIB_PE_CFLAGS, LCMS2_PE_CFLAGS, JPEG_PE_CFLAGS, JPEG_PE_LIBS etc explicitly, and sometimes it get worse. Anyway, I have tried some many things that I thought it might be worth reaching out to the people who maintain the fedora rpm's as well as well wine-devel. A few questions/thoughts: - it seems that the build system is getting confused occasionally about say, native headers vs mingw headers like jpeg-devel; at some point, I got a error saying I was trying to build one of the unixlib.c's with mingw headers, for example. But I see for example that in the generated Makefile for dlls/windowscodecs/ , It is feeding *PE_FLAGS to unixlib.c (plus the PE stub), and I explicitly put -I...mingw32/include to *PE_FLAGS. That seems wrong. - I don't understand why --target=x86_64 rebuild works, built --target=i686 rebuild fails with the above error. My list of mingw32-* packages and mingw64-* packages are almost identical, I think, and certainly regarding libjpeg (zlib/png dependencies) . I have the 29MB combined x86-64 and i686 build-log of 7.3, plus the 15MB x86-64 and ~3MB i686 failure of each of 7.5/7.9/7.10 ; but it is kind of difficult to see what to check. Any hints on what to look at at config.log would be useful. *note rpmbuild detects isdn4k-utils on my system so I needed to add these two lines +%{_libdir}/wine/%{winesodir}/capi2032.so +%{_libdir}/wine/%{winepedir}/capi2032.dll to my modified spec. I suppose I should formalize this part of my diff with one furthe line of BuildRequires: isdn4k-utils-devel as a reminder to myself.
Hi, I posted a a few weeks ago about "Having problems (re-)building i686 wine staging rpm's on fedora" on 7.10. Since 7.11 is out, so I gave it a proper go again with all of fedora's shipping mingw32 packages. Long story short, I think I found the problems, so here they are, mainly two issues: *- In wine's code, there are two directories, "dlls/gphoto2.ds/" and "dlls/windowscodecs/" which tries to build both unix-y bits and PE-y bits. And they have {TIFF,JPEG,...}_PE_CFLAGS feeding to both the unix-y and PE-y bits. I think this is a wine code bug - *_PE_CFLAGS should only be passed to the cross-compiler. - first part of my work-around is simply to delete those lines from "dlls/gphoto2.ds/Makefile.in" "dlls/windowscodecs/Makefile.in" . Since fedora's mingw libjpeg, libtiff, etc are all found normally under its cross-compiler's mingw root without needing special flags. *- "mingw32-pkg-config --cflags libjpeg " etc reports wrong settings at "-I/usr/include" (instead of mingw32 root) on fedora. - 2nd part of my work-around is to explicitly set these (since ming32-pkg-config report wrong): PNG_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ LCMS2_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ ZLIB_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ JPEG_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ TIFF_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ XML2_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2/ XSLT_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2/ The combination of the two issues causes mingw msvcrt headers being used with the native compiler (straight-forward failure), and native glibc headers being used via *_PE_FLAGS="-I/usr/include" when cross-compiling, and have funny issues about time64 being the wrong type during configure, type of "boolean" conflicting, etc in a few places. Anyway, "dlls/gphoto2.ds/Makefile.in" "dlls/windowscodecs/Makefile.in" in wine should be updated to split unix-y and PE-y parts and only feed *_FE_CFLAGS to building the PE-y parts. This is a wine code bug needed fixing, I think. Thanks for everybody working on wine all these years. Regards, Hin-Tak
windowscodecs doesn't have a unixlib anymore, it's all PE. On Tue, Jun 28, 2022 at 12:51 PM Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote:
Hi,
I posted a a few weeks ago about "Having problems (re-)building i686 wine staging rpm's on fedora" on 7.10. Since 7.11 is out, so I gave it a proper go again with all of fedora's shipping mingw32 packages. Long story short, I think I found the problems, so here they are, mainly two issues:
*- In wine's code, there are two directories, "dlls/gphoto2.ds/" and "dlls/windowscodecs/" which tries to build both unix-y bits and PE-y bits. And they have {TIFF,JPEG,...}_PE_CFLAGS feeding to both the unix-y and PE-y bits. I think this is a wine code bug - *_PE_CFLAGS should only be passed to the cross-compiler.
- first part of my work-around is simply to delete those lines from "dlls/gphoto2.ds/Makefile.in" "dlls/windowscodecs/Makefile.in" . Since fedora's mingw libjpeg, libtiff, etc are all found normally under its cross-compiler's mingw root without needing special flags.
*- "mingw32-pkg-config --cflags libjpeg " etc reports wrong settings at "-I/usr/include" (instead of mingw32 root) on fedora.
- 2nd part of my work-around is to explicitly set these (since ming32-pkg-config report wrong):
PNG_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ LCMS2_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ ZLIB_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ JPEG_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ TIFF_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/ XML2_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2/ XSLT_PE_CFLAGS=-I/usr/i686-w64-mingw32/sys-root/mingw/include/libxml2/
The combination of the two issues causes mingw msvcrt headers being used with the native compiler (straight-forward failure), and native glibc headers being used via *_PE_FLAGS="-I/usr/include" when cross-compiling, and have funny issues about time64 being the wrong type during configure, type of "boolean" conflicting, etc in a few places.
Anyway,
"dlls/gphoto2.ds/Makefile.in" "dlls/windowscodecs/Makefile.in" in wine should be updated to split unix-y and PE-y parts and only feed *_FE_CFLAGS to building the PE-y parts. This is a wine code bug needed fixing, I think.
Thanks for everybody working on wine all these years.
Regards, Hin-Tak
participants (3)
-
Esme Povirk (she/they) -
Hin-Tak Leung -
Zebediah Figura