Using the headers from /usr/include
The headers in
/usr/include are for the native libraries installed on the system, and it's highly unlikely they will work for cross-compilation. By "won't work" I mean that types and structure fields could be different, resulting in a segfault.
The Fedora MinGW project takes two steps to avoid using native libraries by accident: Firstly GCC is configured so it looks in
/usr/i686-pc-mingw32/sys-root/mingw/include and
never looks in
/usr/include (as long as you don't tell it to). Secondly we supply a replacement
%{_mingw32_configure} RPM macro which sets
PKG_CONFIG_PATH, so any pkg-config done will pick up the cross-compiled libraries' configuration instead of any native libraries' configuration.
$ PKG_CONFIG_PATH=/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig \
pkg-config --cflags glib-2.0
-mms-bitfields -I/usr/i686-pc-mingw32/sys-root/mingw/include/glib-2.0
-I/usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include
One thing that can still go wrong is that you don't have the cross-compiled library installed and it then picks up the native library. For example, you missed a BuildRequires line. That mistake usually becomes evident when the program tries to link, because linking a cross-compiled Windows binary to a native Fedora library won't work.
Not setting --prefix
You likely don't want to install Windows binaries and libraries under
/usr or
/usr/local. For a start it's better to keep Windows things in one place, and the
packaging guidelines have specified that place to be
/usr/i686-pc-mingw32/sys-root/mingw. But mainly it's not a good idea to mix up native and cross-compiled libraries, which will cause all sorts of problems as in the point above.
If you use
%{_mingw32_configure} in RPM specfiles, or the
mingw32-configure command, then paths will be set correctly for you.
Not using a portability library
If you're writing the program yourself, or if you're doing the often difficult work of
porting an existing application, use a portability library to help you. Which you choose is up to you and depends on many factors, but we would recommend that you look at these ones:
Writing your own build system
While it's fashionable to dislike
autoconf and m4 macros, it is still by far the easiest way to both build your program on multiple systems, and to cross-compile. So use autotools or
cmake, and definitely don't write your own build system. Discourage other projects from writing their own build systems too.
This really comes down to bitter experience. Every project we have had to port that has used its own build system has been far more of a headache than those that just used autoconf or cmake.
Running programs during the build process
When cross-compiling, it's always a mistake to run programs during essential build steps. The problem is that you can't be sure that binaries can be made to work in the build environment. For Windows binaries, there is some chance of running them under
Wine, but Wine itself is incompatible with autobuild environments like
mock and
Koji. Furthermore Wine only works on x86 platforms, and it's not possible to use it at all when cross-compiling from other architectures like PPC.
Running programs during
make test is normal and useful though.
