GNOME Bugzilla – Bug 731013
Cross-compilation from Linux to Windows broken as of gtk+ 3.13.2 (moved extract-strings)
Last modified: 2017-08-24 23:00:23 UTC
As of gtk+ 3.13.2 cross-compilation (from a Linux host to a mingw-w64 Windows target) has become broken: Making all in util make[2]: Entering directory `/builddir/build/BUILD/gtk+-3.13.2/build_win32/util' make[2]: Leaving directory `/builddir/build/BUILD/gtk+-3.13.2/build_win32/util' make[2]: *** No rule to make target `extract-strings.exe', needed by `all-am'. Stop. make[1]: Leaving directory `/builddir/build/BUILD/gtk+-3.13.2/build_win32' make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Full build logs @ http://koji.fedoraproject.org/koji/getfile?taskID=6909593&name=build.log This regression is introduced by commit https://git.gnome.org/browse/gtk+/commit/?id=a28d2cb9233eff0983b7b3517a9dbb00b62fd357 in which Matthias Clasen has explicitly stated that it breaks cross-compilation. In Fedora we've workarounded it for now by doing a partial revert of the commit in question, but this should be fixed properly in upstream gtk+ so other cross-compiler package maintainers don't have to workaround it as well.
As I said in that commit message, a patch would be very appreciated.
Created attachment 283247 [details] [review] Patch against master It's not a good idea to use a *_PROGRAMS target because automake tries to be clever by adding the $(EXEEXT) which is not what we want here. The previous implementation was ok, because extract-strings was built as a dependency, which does not add $(EXEEXT). So we must do the same again, and the one target which we know will be run is `all`. So I made extract-strings a dependency of all-local. And that fixes it! Patch attached.
Review of attachment 283247 [details] [review]: Makes sense.
This patch does not break anything for me.
As discussed on IRC with ebassi and LRN, patch committed: commit 651d9e90e715ba0f4e246d03102cfb5353c19dc6 Author: Jehan <jehan@girinstud.io> Date: Wed Aug 13 05:08:08 2014 +0000 Bug 731013 - cross-compilation broken when building extract-strings It is actually a bad idea to use noinst_PROGRAMS for build tools, because it adds a $(EXEEXT). It is best to override the all target with all-local to trigger the tool build.
I see my commit has been reverted as of: commit f4a29fbfc28b1c9918de939b616f61738d27a17a Author: Rico Tzschichholz <ricotz@ubuntu.com> Date: Fri Aug 15 17:40:55 2014 +0200 Revert "Bug 731013 - cross-compilation broken when building extract-strings" This reverts commit 651d9e90e715ba0f4e246d03102cfb5353c19dc6. The commit broke 'make dist' - the extract-strings sources are no longer included in the tarball. ------------------------- Well it's true that I have forgotten to do a make dist. I think that being not a noinst_PROGRAMS anymore, the sources were skipped. Well that should be easy to fix, though I don't have time to do it right now. So I reopen this report because this revert broke again the cross-compilation of master.
The patch mentioned here doesn't work correctly when cross-compiling from Linux to the Win64 target: make[2]: Entering directory '/home/erik/fedora/mingw-gtk3/gtk+-3.13.8/build_win64/util' x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../util -I.. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -fvisibility=hidden -MT extract_strings-extract-strings.o -MD -MP -MF .deps/extract_strings-extract-strings.Tpo -c -o extract_strings-extract-strings.o `test -f 'extract-strings.c' || echo '../../util/'`extract-strings.c mv -f .deps/extract_strings-extract-strings.Tpo .deps/extract_strings-extract-strings.Po /bin/sh ../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -fvisibility=hidden -o extract-strings.exe extract_strings-extract-strings.o -lgobject-2.0 -lgmodule-2.0 -pthread -lglib-2.0 -lm -lintl libtool: link: x86_64-w64-mingw32-gcc -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -fvisibility=hidden -o .libs/extract-strings.exe extract_strings-extract-strings.o -pthread -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -pthread extract_strings-extract-strings.o: In function `main': /home/erik/fedora/mingw-gtk3/gtk+-3.13.8/build_win64/util/../../util/extract-strings.c:153: undefined reference to `g_file_get_contents' collect2: error: ld returned 1 exit status Makefile:487: recipe for target 'extract-strings.exe' failed This failure is caused by invalid CFLAGS. The correct cross-compiler is used here (x86_64-w64-mingw32-gcc), but the CFLAGS point to the native headers (/usr/include/glib-2.0 and /usr/lib64/glib-2.0/include) instead of the cross-compiled headers
Additionally: the results in my previous comment are based on a pristine gtk 3.13.8 which contains an alternative fix for this bug (https://github.com/GNOME/gtk/commit/62254ca3061a1309e836939df242140b53c79603) than the one from Jehan mentioned here in comment 5 in this bug report. To summarize: gtk+ 3.13.8 can't be cross-compiled for the win64 target and when trying to cross-compile it for the win32 target the non-UTF8 variant of the symbol g_file_get_contents gets used in the extract-strings.exe tool which can lead to undesired side effects
The patch is not applied on the repository (or rather it has been reverted, cf. comment 6). Unless you mean you applied it yourself, but since I see extract-strings.exe, whereas you write the build platform is Linux, I assume you haven't done so, have you?
> Additionally: the results in my previous comment are based on a pristine gtk 3.13.8 which contains an alternative fix for this bug (https://github.com/GNOME/gtk/commit/62254ca3061a1309e836939df242140b53c79603) Well here is your problem, I think. It removed the custom build call ("$(AM_V_CCLD)$(CC_FOR_BUILD) ..."). noinst_PROGRAMS by itself won't know you are trying to build for the native platform and will try to build the program as the rest of the program (which is not what we want here, we want to build for the build platform, i.e. Linux in your case). That's why you'll have a mix of build and target-related things in the command line. In our case, x86_64-w64-mingw32-gcc is in fact *NOT* the correct compiler. We want the usual native gcc. Anyway I'll check again my patch and make so it won't break `make dist` next time. But I won't have time to do this before a few days. In the meantime, you can probably use the patch attached. It will work fine for a simple build.
Thanks for your quick response. Your patch from comment 5 could not be applied on top of gtk+ 3.13.8. I had to revert commit 62254ca3061a1309e836939df242140b53c79603 first before I was able to apply your patch. With this situation I could cross-compile gtk+ for both win32 and win64 targets without issues. Here's the make output related to the extract-strings tool: make[2]: Entering directory '/home/erik/fedora/mingw-gtk3/gtk+-3.13.8/build_win64/util' gcc -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -O2 ../../util/extract-strings.c -lgobject-2.0 -lgmodule-2.0 -pthread -lglib-2.0 -o extract-strings make[2]: Leaving directory '/home/erik/fedora/mingw-gtk3/gtk+-3.13.8/build_win64/util' This looks like the correct combination of compiler and cflags to me, so your patch looks like a better fix than the one from commit 62254ca3061a1309e836939df242140b53c79603
Yes 62254ca3061a1309e836939df242140b53c79603 is definitely not the proper fix. Just seeing the diff, even if it may work in some cases, it is doomed to fail at some point. My previous patch was definitely more adapted (I don't say that's the best fix though, at least it makes some sense), but it was breaking the packaging (make dist). My bad, I should have tested all the way, not stopping to build/install. Anyway I will come back to this at some point and try to have it integrated again. :-)
Created attachment 287100 [details] [review] Fix cross compilation
Tested and I can confirm this patch solves the problem about cross-compiling.
extract-strings is gone in all version of GTK+ now.