GNOME Bugzilla – Bug 708993
Cross compiling GTK+2 on Linux for Windows with mingw64 fails.
Last modified: 2014-08-13 19:03:43 UTC
Created attachment 255984 [details] [review] Patch fixing cross-compilation on Linux for Windows. I have been trying to cross-compile GTK+ on a Linux machine for Windows, using mingw 64. And it was failing either during the make or the make install for a few reasons: 1/ The binaries gtk-update-icon-cache and gtk-query-immodules-2.0 have a .exe when compiled for Windows, so the make could not find them after compilation. Fixed with adding a $(EXEEXT). 2/ modules/engines/ms-windows/ and modules/other/gail were missing gmodule-2.0 compilation and linking data, which was problematic actually in particular at linking steps. 3/ CROSS_COMPILING test was checking a variable $cross_compiling which was defined basically nowhere. So the few pieces of Makefile which was relying on this CROSS_COMPILING were seeing my building as *not* cross-compiling (obviously wrong). In particular it ended up making some tests in modules/input/Makefile.am, which were not supposed to be run when cross-compiling, and this would break the `make install`. This is fixed by a $host != $build test. These 3 issues are fixed by the attached patch, with which I am now able to fully compile GTK+. It has been tested on gtk-2-24 branch, freshly pulled. I have not checked if the same problem occurs in GTK+ 3, because I am a GIMP developer. But I could try to cross-compile GTK+ 3 later, and see if the issues occurs, and if the same commit would fix it.
Review of attachment 255984 [details] [review]: First part of a review. Sorry, but ran out of time to look at the Makefile.am changes, will look again later... ::: configure.ac @@ +914,3 @@ dnl Look for a host system's gdk-pixbuf-csource if we are cross-compiling +AM_CONDITIONAL(CROSS_COMPILING, test $host != $build) Looks weird to me as $cross_compiling should be set by autoconf: http://www.gnu.org/software/autoconf/manual/autoconf.html#index-cross_005fcompiling-1186 and https://git.gnome.org/browse/gtk+/commit/?id=db9df57df14193c02d926f841cac7337ecf70609
Hmmm... ok well it was definitely not set to 'yes' when I built. So there is a problem somewhere. But maybe it is not the right way to fix it. Now when I looked a few lines above, I read this: « If cross-compilation mode is enabled (this is the case if either the compiler being used does not produce executables that run on the system where configure is being run, or if the options --build and --host were both specified and their values are different) » They don't say if this "cross-compilation mode" is equivalent to cross_compiling="yes", but I would imagine that it is. In any case, I don't cross-compile with both --build and --host, only --host, and use the default guessed build (because it successfully guesses my Linux OS right). I would do something like this: $ ./configure --host=x86_64-w64-mingw32 In any case, if we really *have to* set both --host *AND* --build, I'd say that the autotools are bugged. I will check the autotools code and maybe propose a patch upstream, but I would still propose we use my proposed workaround in the meantime (after all, they say in the doc too this is also the way they determine the cross-compilation mode, by checking if build and host values are different).
Oh looking for more information in the autoconf doc, I spotted this: « If you mean to override the result of config.guess, use --build, not --host, since the latter enables cross-compilation. For historical reasons, whenever you specify --host, be sure to specify --build too; this will be fixed in the future. So, to enter cross-compilation mode, use a command like this ./configure --build=i686-pc-linux-gnu --host=m68k-coff » So they indeed ask to specify --build explicitly, but they also say this is a bug that would be fixed in the future.
Ok so I checked autoconf code and I understood fully my problem after a few tests. Basically as said above, they advise to set --host AND --build for historical reason. But if you set only --build, autoconf would still try to check whether we are cross-compiling. It does so by trying and run a test executable. The problem occurs with modern GNU/Linux OSes which set Wine to automatically run for Windows executable, even without asking on the command line! Debian and derivative uses `update-binfmts` for this. This was the default behavior on my Linux Mint, and can be disabled with: $ update-binfmts --disable wine Unfortunately users have to look it up. I didn't know about this myself! Anyway I made a patch and a bug report for autoconf: https://savannah.gnu.org/support/index.php?108405 I would still propose to keep the line in my patch: +AM_CONDITIONAL(CROSS_COMPILING, test $host != $build) Because I consider this is to be considered as a bug of autoconf, unable to detect a basic cross-compilation case on modern OSes (Wine being quite a common default package in many distributions now). I could just add a comment line above it to explain why we don't test against $cross_compiling instead.
Created attachment 257986 [details] [review] New patch, simpler, which works when setting both --build and --host. Hi again, so if I set a --build too, and not only a --host (as described above), some of the compilation bugs disappear. Well that should still be better, but it can be argued that autoconf doc currently advises to set --host AND --build for retro-compatibility reasons. So here would be the simpler patch which fixes the remaining bugs, once cross-compilation has been successfully detected.
Updating title since I checked GTK+3 and all these fixes apply only to GTK+2 (note: I've opened a separate bug 711772 with a different patch for different bugs applying to GTK+3). Anyway can this patch be applied to gtk-2-24 branch? Has anyone tested it? I'm speaking of the simpler one. The $cross_compiling which you found strange is unneeded anymore as long as I set a --build too on my configure.
Anyone had a look at my small patch? I checked against current gtk-2-24 branch. Cross-compilation would still fail on linking 2 modules because of missing references to some gmodule functions. Attachment 257986 [details] still seems necessary. Could we push the commit?
Hi, Noone to review this 4-line patch? I've checked, this patch is still necessary to cross-compile and it still works on HEAD of gtk-2-24 branch. As a member of the GIMP team, if none really cares about ensuring that GTK+ compiles well for Windows too, I would be ok to maintain this specific part of the library. I regularly cross-compile GTK+ for testing and debugging GIMP on my Windows 7 VM.
shouldn't $(GMODULE_LIBS) only be needed when building on Windows, instead of unconditionally? it's a bit weird, and I'm worried of side effects; it would be great if you could join the #gtk+ IRC channel and talk with the people currently building GTK+ for Windows.
Created attachment 283248 [details] [review] Updated patch. I did make a native build with this change on Linux, and it did not do any issue. But well if you want to be sure, why not. Obviously I didn't need to change modules/engines/ms-windows/Makefile.am since this one is only run when the target in win32 (cf. modules/engines/Makefile.am), but I updated for the other Makefile. Updated patch attached. I can come on IRC, but not today. I'm tired. :P
As discussed on IRC with ebassi and LRN, patch committed: commit ab3e3b1834ff0e8a98fd689bbb85b84f3cbbc962 Author: Jehan <jehan@girinstud.io> Date: Thu Oct 24 19:42:44 2013 +1300 Makefiles: cross-compilation on Linux for Windows failing. Missing linking information for some modules.