Having problems (re-)building i686 wine staging rpm's on fedora
Hin-Tak Leung
htl10 at users.sourceforge.net
Thu Jun 16 16:32:36 CDT 2022
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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220616/810770e3/attachment.htm>
More information about the wine-devel
mailing list