GNOME Bugzilla – Bug 691301
Better support for cross-compiling
Last modified: 2013-01-10 15:16:03 UTC
When cross-compiling GTK+ 3, having a native installation of GTK+ is a prerequisite for the gtk-icon-cache-update binary. As we (yoctoproject.org) don't want to list gtk+ as a host dependency this means that to cross-compile GTK+ we need to natively build glib, gdk-pixbuf, libX11 and friends, ATK, Pango... However by just having a native gdk-pixbuf it's possible to build a native gtk-update-icon-cache and use that. configure knows when it's cross compiling, and there's a defacto standard for passing in CC/LD/CPPFLAGS/LDFLAGS etc to configure which can be extended for a native pkg-config. My basic proposal is: 1) at configure time, if cross-compiling use native tools to find gdk-pixbuf instead of insisting that gtk-update-icon-cache is present 2) at build time, if cross-compiling build a noinst native-icon-cache-update alongside the installed gtk-icon-cache-update. Thanks to automake you can't override CC per-target, so this does have to be done in a separate directory.
Created attachment 232912 [details] [review] build: support cross-compilation by natively building gtk-icon-cache-update Very much work in progress, but does actually work.
It's possibly worth allowing the use of a pre-existing gtk-icon-cache-update for people who have one, and it would be sensible to move the native-pkgconfig macro into m4/ (I have grandiose plans of upstreaming that too).
Oh, and use the autostars macros to handle/check CC_FOR_BUILD etc nicely (as mesa does).
Review of attachment 232912 [details] [review]: This looks quite reasonable to me, and solves a real problem. I have some comments, but this patch looks fine to me to commit as is without addressing them. When you say "work in progress", what further work did you have in mind? ::: gtk/Makefile.am @@ +1580,3 @@ if !USE_EXTERNAL_ICON_CACHE +if CROSS_COMPILING + $(AM_V_at) $(MAKE) $(AM_MAKEFLAGS) -C native/ Recursively invoking make here is pretty ugly, but it's also not a regression. Hm, these contortions seem to be so that gtkbuiltincache.h can be shipped in tarballs, but still generated via git. What if we switched to *always* generating it? Then gtkbuiltincache.h could simply depend normally on $(gtk_update_icon_cache_program). You don't have to do this, but I wonder if any of the GTK+ maintainers would object. ::: gtk/native/Makefile.am @@ +1,1 @@ +CC = $(CC_FOR_BUILD) Hm...is this sort of thing really the best practice for doing host compilation with Automake? It's kind of ugly since it forces use of recursive automake. I guess this still the best reference, 9 years later? http://lists.gnu.org/archive/html/automake/2004-01/msg00084.html
(In reply to comment #3) > Oh, and use the autostars macros to handle/check CC_FOR_BUILD etc nicely (as > mesa does). I'm curious, but: $ git describe mesa-9.0.1-3-gc80abac $ git grep CC_FOR_BUILD $ I'm not seeing anything in configure.ac; but if other projects with host tool needs have macros we can steal, that sounds good.
The mesa changes are in master, not 9.0.x (although I did suggest backporting the changes).
> When you say "work in progress", what further work did you have in mind? Mainly using the autostar macros to check/handle CC_FOR_BUILD nicely. > Recursively invoking make here is pretty ugly, but it's also not a regression. You'd think that using "SUBDIRS=a11y native . tests" would be sufficient, but before recursing automake builds all BUILT_SOURCES: all: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) all-recursive So we need to force a make in native/ first. :( > Hm...is this sort of thing really the best practice for doing > host compilation with Automake? It's kind of ugly since it > forces use of recursive automake. Yes :( CC et al can't be overriden per-target. If GTK+ wanted to move to single-makefile, it would have to be two-makefiles, one for the native tools and one for everything else.
Created attachment 233025 [details] [review] build: support cross-compilation by natively building gtk-update-icon-cache When cross-compiling, instead of depending on a natively built GTK+ (which means building Glib, ATK, Pango, gdk-pixbuf, libX11...) for gtk-update-icon-cache, find the host compiler and gdk-pixbuf, and build another gtk-update-icon-cache with that. This uses AX_PROG_CC_FOR_BUILD from autostars to find the host compiler, and assumes that you'd set PKG_CONFIG_FOR_BUILD to a host pkg-config binary.
That's mk2. I'll do some proper testing tomorrow and confirm that it doesn't regress anything. Oh, and it's against 3.4.4 right now so I'll rebase to master.
Created attachment 233056 [details] [review] build: support cross-compilation by natively building gtk-update-icon-cache When cross-compiling, instead of depending on a natively built GTK+ (which means building Glib, ATK, Pango, gdk-pixbuf, libX11...) for gtk-update-icon-cache, find the host compiler and gdk-pixbuf, and build another gtk-update-icon-cache with that. This uses AX_PROG_CC_FOR_BUILD from autostars to find the host compiler, and assumes that you'd set PKG_CONFIG_FOR_BUILD to a host pkg-config binary.
Review of attachment 233056 [details] [review]: Just a few minor comments, looks good to me to commit after addressing them. ::: configure.ac @@ +871,3 @@ AM_CONDITIONAL(CROSS_COMPILING, test $cross_compiling = yes) +if test "x$enable_gtk2_dependency" = xyes; then While you have the patient open, change this to use AS_IF() please - see https://bugzilla.gnome.org/show_bug.cgi?id=681413. @@ +879,3 @@ + # If no GTK+2 dependency and cross compiling, we need to find a host gdk-pixbuf. + # pkg.m4 blocks all variable starting with PKG, so allow this one + m4_pattern_allow([PKG_CONFIG_FOR_BUILD]) Is PKG_CONFIG_FOR_BUILD something that the meta-build system (e.g. bitbake recipe, rpm spec file) is supposed to define? I don't see it in ax_prog_cc_for_build.m4, nor pkg.m4. If so, should probably add document it somehow...maybe just do: AS_IF([test x$PKG_CONFIG_FOR_BUILD = x], [AC_MSG_ERROR([You must define PKG_CONFIG_FOR_BUILD when cross compiling]) ? @@ +881,3 @@ + m4_pattern_allow([PKG_CONFIG_FOR_BUILD]) + AC_MSG_CHECKING([for native gdk-pixbuf]) + if AC_RUN_LOG([$PKG_CONFIG_FOR_BUILD --exists --print-errors gdk-pixbuf-2.0]); then And this needs to use AS_IF too - it's more important here because I bet this is the first use of AC_RUN_LOG.
Ported to AS_IF. Yes, that PKG_CONFIG_FOR_BUILD is assumed to be provided, and I just made it up. I've added that error case.
Created attachment 233148 [details] [review] build: support cross-compilation by natively building gtk-update-icon-cache When cross-compiling, instead of depending on a natively built GTK+ (which means building Glib, ATK, Pango, gdk-pixbuf, libX11...) for gtk-update-icon-cache, find the host compiler and gdk-pixbuf, and build another gtk-update-icon-cache with that. This uses AX_PROG_CC_FOR_BUILD from autostars to find the host compiler, and assumes that you'd set PKG_CONFIG_FOR_BUILD to a host pkg-config binary.
Review of attachment 233148 [details] [review]: Looks good!
Comment on attachment 233148 [details] [review] build: support cross-compilation by natively building gtk-update-icon-cache Committed to master, thanks Colin.