"1. Specifying --build should not be necessary, as it should default to"

correct.

"2. what are the implications of AC_CHECK_TOOLS wrt. the current
AC_CHECK_PROGS invocations?"

AC_CHECK_TOOLS checks for TARGET-PROG, so it uses the proper cross
compile tools.

"There is a lot of logic to determine the C++ compiler...  "

Good point. This uses AC_CHECK_TOOLS too now.

"3. should we include config.sub? Can we share it easily with the libffi
one? Where do I get the most recent version of it?"

config.sub comes from autoconf, and if libffi uses it, it should be
the same one.

It's a bad idea to put generated files in SVN, as is done now; the
same holds for the toplevel configure.  Standard practice is to
include an autogen.sh script that will invoke the correct
autoconf/automake/aclocal/acheader/etc. voodoo to generate the
scripts.

"4. Where does the mapping of system names from -dumpmachine come from?
What would need to be done to eliminate this altogether? What about
ac_sys_release?"

The mapping has to be maintained by someone.  It's not very elegant,
but then again, there are some arbitrary mappings in configure.in in
the native build for ac_sys_release. IMO it would be better to do away
with this completely and use the autoconf/config.sub naming
exclusively.

"5. Isn't there some autoconf way for detecting a C compiler for the build
system? It shouldn't default to 'cc'."

I'm not aware of any; what do you think the default should be, if not
cc?  (There is AC_PROG_CC, but that will look for the X-compiler).

"6. I don't think the "skipping import check" warning is needed. Just
silently don't perform this check."

OK. - note that there are several other "skipping import check"
messages, for cygwin and Carbon.

"7. What is the meaning of CROSS_TARGET? In some place, it is used like
sys.platform (so it should take one of the possible values for
sys.platform), in configure.in, it is set to ac_sys_system.  I think you
should just use MACHDEP here."

Good point. I changed this.

"8. Why is /usr/local/lib excluded when cross-compiling? Please add a
comment (likewise for lib64)"

/usr/local/lib/ in general contains libraries for the build system,
not the target system. Linking them in will either generate bogus
linker errors ("wrong architecture binary") or worse create a module
which isn't loadable on the target platform, because the library is
missing there.

I've added a more generic mechanism, which filters include_dirs so
they can only start with $CROSS_ROOT.  Something similar should really
be applied to the linker directories, but I'm not sure which variable
to modify.

"Otherwise, it looks fine; I haven't been able to test it yet, though."

I've added some more information.  If you want to get a cross-compile
environtment, you could do

  mkdir gub ; cd gub ; git init ; git pull git://git.sv.gnu.org/lilypond.git gub:
  make -f lilypond.make PLATFORMS="freebsd-x86" cross-compilers

this will leave a cross compiler in
gub/target/freebsd-x86/usr/cross/bin

File Added: cross-55748.patch