GNOME Bugzilla – Bug 696951
Cross compiling for win32 fails to build native_update_icon_cache
Last modified: 2014-10-11 21:18:53 UTC
When cross compiling gtk 3.8.0 on build system linux for host system win32, the build fails when trying to build a native gtk-update-icon-cache version for the build system. The error is: [ 76s] make[3]: Entering directory `/home/abuild/rpmbuild/BUILD/gtk+-3.8.0/gtk/native' [ 76s] CC native_update_icon_cache-updateiconcache.o [ 76s] In file included from /usr/include/stdlib.h:320:0, [ 76s] from ./../updateiconcache.c:21: [ 76s] /usr/include/sys/types.h:66:17: error: two or more data types in declaration specifiers [ 76s] /usr/include/sys/types.h:81:17: error: two or more data types in declaration specifiers [ 77s] make[3]: *** [native_update_icon_cache-updateiconcache.o] Error 1 The problem is that when trying to build the native gtk-update-icon-cache for the build system gtk/updateiconcache.c includes "config.h", which is generated for the host system (win32), not for the build system (linux). The config.h for win32 is defining gid_t, which causes the error in types.h. Clearly, it is not a good idea to use the config.h generated for the host system in a compilation for the build system. This error was introduced when fixing https://bugzilla.gnome.org/show_bug.cgi?id=691301 in commit 53083ea7b423482b203372f02d097edbef894a7d Possible(?) solutions I can think of: - generate a separate config.h for the build system. (unfortunately I have no idea how to do this) or: - when cross compiling, avoid trying to build a native gtk-update-icon-cache and use the system one instead. Maybe still try to build a native gtk-update-icon-cache when the build system does not have one (which fails in this case, but might be good enough for others). (if desired, I can create a patch for this solution).
To work around this issue, you can add --enable-gtk2-dependency to ./configure. This will force the use of the build system's gtk-update-icon-cache. However, this will also cause gtk-query-immodules-3.0.exe, gtk-launch.exe and gtk-update-icon-cache.exe not to be build at all.
I've been trying to cross-compile to MinGW target, and there's several other problems in addition to config.h one (that one I got around by not including config.h if NATIVE_BUILD is defined, and defining it in native/Makefile.am native_update_icon_cache_CFLAGS) - configure.ac:620 adds INTLLIBS to LIBS, causing -lintl tobe used in native build too - linking failure - I'm not yet sure if it causes problems but EXEEXT suffix is added to executable name also in native build
For the record: I just got gtk+-3.8.1 cross-compile to work from Linux host to MinGW in my build scripts. Unfortunately patches to do that are not generally acceptable ("this makes MY use-case to work" & patch configure instead of configure.ac etc). In case someone finds that useful, they are part of crosser project ( http://www.cazfi.net/crosser/ ) svn HEAD ( svn://svn.cazfi.net/crosser/trunk )
Created attachment 241754 [details] [review] Fix for INTLLIBS problem Cleaned up my patches a bit, so submitting here for others to say if that kind of solution would be acceptable.
Created attachment 241755 [details] [review] Fix for config.h include part
(In reply to comment #5) > Created an attachment (id=241755) [details] [review] > Fix for config.h include part Not including config.h for a native build sounds like ignoring the issue that a proper config.h for the native build should be included when building gtk-update-icon-cache. It is just luck that the build succeeds without a config.h.
Seems like Autoconf prefers it this way: "Note that you should not include `config.h' in a file you are compiling with `$(CC_FOR_BUILD)'. The `configure' script will build `config.h' with information for the host system. However, you are compiling the file using a compiler for the build system (a native compiler). Subsidiary programs are normally simple filters which do no user interaction, and it is often possible to write them in a highly portable fashion so that the absence of `config.h' is not crucial." (From autobook: http://www.sourceware.org/autobook/autobook/autobook_270.html) So, it seems like gtk-update-icon-cache shouldn't use config.h and currently Autoconf doesn't provide any alternative. Also the next paragraph says something about rtl.c in GCC. I tried checking it out and it seems a shell script creates bconfig.h - config.h for the build system, but seems like it only creates a simple one.
Tried compiling the native update-icon-cache and it seems like it is compiled as a Windows executable instead of the build, which is Linux: kyoushuu@kyoushuu-netbook-opensuse:~/gtk+-3.8.1/gtk/native> make V=3 gcc -DHAVE_CONFIG_H -I. -I../.. -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng15 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DNATIVE_BUILD -g -O2 -MT native_update_icon_cache-updateiconcache.o -MD -MP -MF .deps/native_update_icon_cache-updateiconcache.Tpo -c -o native_update_icon_cache-updateiconcache.o `test -f './../updateiconcache.c' || echo './'`./../updateiconcache.c mv -f .deps/native_update_icon_cache-updateiconcache.Tpo .deps/native_update_icon_cache-updateiconcache.Po /bin/sh ../../libtool --tag=CC --mode=link gcc -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng15 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DNATIVE_BUILD -g -O2 -o native-update-icon-cache native_update_icon_cache-updateiconcache.o -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 libtool: link: gcc -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng15 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DNATIVE_BUILD -g -O2 -o .libs/native-update-icon-cache native_update_icon_cache-updateiconcache.o -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -pthread kyoushuu@kyoushuu-netbook-opensuse:~/gtk+-3.8.1/gtk/native> file native-update-icon-cache.exe native-update-icon-cache.exe: PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows I tried running it using Wine or bash, but it doesn't run at all. By adding --debug to libtool, I found out that the source file is compiled into an object file using gcc then it is linked by libtool using i686-w64-mingw32-gcc. I used the sources of GTK+ 3.8.1 with the INITGUID (from OpenSUSE Build Service) and the two patches attached here applied. It is configured using 'PKG_CONFIG_FOR_BUILD="env PKG_CONFIG_PATH=/usr/lib/pkgconfig /usr/bin/pkg-config" mingw32-configure --disable-cups --disable-schemas-compile --with-included-immodules=yes' (which expands to something like './configure --cache-file=mingw32-config.cache --host=i686-w64-mingw32 --build=x86_64-suse-linux-gnu --target=i686-w64-mingw32 --prefix=/usr/i686-w64-mingw32/sys-root/mingw --exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw --bindir=/usr/i686-w64-mingw32/sys-root/mingw/bin --sbindir=/usr/i686-w64-mingw32/sys-root/mingw/sbin --sysconfdir=/usr/i686-w64-mingw32/sys-root/mingw/etc --datadir=/usr/i686-w64-mingw32/sys-root/mingw/share --includedir=/usr/i686-w64-mingw32/sys-root/mingw/include --libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib --libexecdir=/usr/i686-w64-mingw32/sys-root/mingw/libexec --localstatedir=/usr/i686-w64-mingw32/sys-root/mingw/var --sharedstatedir=/usr/i686-w64-mingw32/sys-root/mingw/com --mandir=/usr/i686-w64-mingw32/sys-root/mingw/share/man --infodir=/usr/i686-w64-mingw32/sys-root/mingw/share/info --disable-cups --disable-schemas-compile --with-included-immodules=yes --disable-introspection', according to config.log).
Created attachment 242909 [details] [review] Look for system update-icon-cache when cross compiling
For the comments here it is clear that there are many issues when trying to build a native-update-icon-cache when cross compiling. IMHO, it is almost impossible to do that reliably. I would strongly suggest to prefer using the system update-icon-cache when available, and only try the native-update-icon-cache route as a last resort. It keeps cross compiling easier (no need to set PKG_CONFIG_FOR_BUILD) and more reliable. Attachment 242909 [details] does just that.
Ross, you added the native-update-icon-cache route in the 3.8 cycle. Can you give my patch a review?
Created attachment 244061 [details] [review] 0001-Fix-compiling-native-update-icon-cache-for-cross-com.patch On second thought, building a working native update-icon-cache when cross compiling seems doable after all. See this patch.
Why do you need to do all that, when the end result appears to be just adding -DNO_CONFIG_H?
(In reply to comment #13) > Why do you need to do all that, when the end result appears to be just adding > -DNO_CONFIG_H? See comment 8, if you use automake stuff the resulting Makefile.in uses libtool which will link with the $host linker instead of the $build linker.
This bug has been first mentioned here: https://bugzilla.gnome.org/show_bug.cgi?id=696750. Please link it. Thanks, Andrey
I think this bug was fixed by https://git.gnome.org/browse/gtk+/commit/?id=4376b4f705baec38e79449525e506bf4d28de4d2