building i686 wine rpm's on fedora revisted, bug found, etc

Hin-Tak Leung htl10 at
Tue Jun 28 12:51:11 CDT 2022


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/" "dlls/windowscodecs/" . 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):


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.


"dlls/gphoto2.ds/" "dlls/windowscodecs/" 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wine-devel mailing list