GNOME Bugzilla – Bug 673911
gio-2.0.pc lists full path to executables, breaking cross compiling
Last modified: 2012-04-11 19:32:26 UTC
During the 2.31 development cycle, gio-2.0.pc has grown two new variables with full path to helper tools: > glib_compile_schemas=@bindir@/glib-compile-schemas@EXEEXT@ > glib_compile_resources=@bindir@/glib-compile-resources@EXEEXT@ This causes trouble when cross compiling, because it's not possible to execute the target system's binaries. Instead, the builds are supposed to use the native versions of the tools that are installed on the build host. Historically, glib-2.0.pc has avoided using full path and just listed the executable name: > glib_genmarshal=glib-genmarshal > gobject_query=gobject-query > glib_mkenums=glib-mkenums This approach works better because then the correct tools are picked up from PATH. I would like to fix this by removing full paths from these variables in gio-2.0.pc. This also avoids the mess where some tools are picked up from PATH and some from the .pc file. For example, most consumers currently use AC_PATH_PROG(GLIB_GENMARSHAL, glib-genmarshal) to pick up glib-genmarshal, but glib-compile-resources is instead picked up from the .pc file: > GLIB_COMPILE_RESOURCES=`$PKG_CONFIG --variable glib_compile_resources gio-2.0` > AC_SUBST(GLIB_COMPILE_RESOURCES) It would be cleaner to also use AC_PATH_PROG() for glib-compile-resources in consumers.
Created attachment 211836 [details] [review] gio-2.0.pc: Avoid full path to executables Instead of using full path in glib_compile_schemas and glib_compile_resources variables, rely on having the executables in PATH. This fixes the cross-compiling case where we cannot execute the binaries for target system. Instead of executing the target system's binaries, we need to use the native versions installed on the build host. The easiest way to find the native executables is to just pick them up from PATH. In addition, this brings gio-2.0.pc in line with glib-2.0.pc -- the latter has historically only listed the executable name and not the full path.
Review of attachment 211836 [details] [review]: Hm, so you're dropping @EXEEXT@ here in addition to the directory path. Isn't that going to break windows?
It should be fine on Windows: both msys bash and cmd.exe handle executable names without .exe extension without a problem. Also, CreateProcess() documentation on MSDN [1] says this: > If the file name does not contain an extension, .exe is appended. /.../ If the > file name ends in a period (.) with no extension, or if the file name contains > a path, .exe is not appended. Besides, glib-2.0.pc has had glib_genmarshal=glib-genmarshal in the .pc file for a long time and gotten away with it, so I'd assume this hasn't been an issue on Windows. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
Ok, makes sense; consider the patch a-c-n.
Thanks, pushed to master as 4769284.