I’ve noticed that there are a number of checks like this in various configure.ins:
MY_AC_PATH_PROG(FT_CONFIG, ${ac_tool_prefix}freetype-config, no)
The pkgsrc framework automatically sets the --host option (among other things) on configure, which causes ac_tool_prefix to be set to something like x86_64-sun-solaris2.11. The problem is that in this case (and others), there is no x86_64-sun-solaris2.11-freetype-config, only freetype-config. That causes a lot of dependencies to be left unfound, which isn’t ideal. I notice that the check for gcc falls back to gcc, so it’s possible there’s a bug in autoconf itself.
Would anyone care to offer an opinion as to the proper solution to this problem? I could create a bunch of symlinks, but that doesn’t seem like the best way to solve this (though it might be the quickest).
Bill
In current autoconf there is AC_PATH_TOOL which tries both with and without the prefix, and which prints a warning if the tool is only found without the prefix and cross compiling is in effect.
My suggestion would be to replace instances of MY_AC_PATH_PROG which specify ${ac_tool_prefix} (and possibly some that don't) with calls to a new function MY_AC_PATH_TOOL, which mimics this behaviour (but which is implemented using AC_PATH_PROGS), except that I think binaries without prefix should be ignored rather than warned about when cross-compiling. There is nothing wrong with having "freetype-config" installed when cross-compiling, so it does not warrant a warning, but using it for the cross-compilation will give incorrect results, so we shouldn't.
Something like this:
define(MY_AC_PATH_TOOL,[ if test "x$enable_binary" = "xno"; then AC_PATH_PROG($1,nobinary_dummy,$3,$BINDIR) elif test "x$cross_compiling" = "xyes" -o "x$ac_tool_prefix" = "x"; then AC_PATH_PROG($1,${ac_tool_prefix}$2,$3,$4) else AC_PATH_PROGS($1,${ac_tool_prefix}$2 $2,$3,$4) fi ])
pike-devel@lists.lysator.liu.se