------- Comment #6 from wilson at gcc dot gnu dot org 2008-02-01 23:39 -------
Configuring --without-x is a possible workaround. I haven't tried it. I also
haven't tried to reproduce the problem.
The problem comes from the AC_PATH_XTRA call in libjava/configure.ac. This is
a documented autoconf feature to get info about X header files and libraries.
So now we have to look in the autoconf sources. AC_PATH_XTRA calls AC_PATH_X.
If X is enabled, and x_includes/x_libraries have not already been specified,
then _AC_PATH_X is called. _AC_PATH_X then calls _AC_PATH_X_XMKMF.
_AC_PATH_X_XMKMF then does something clever. It creates an Imakefile that just
echos the value of some Imakefile variables, it runs xmkmf to convert the
Imakefile into an X makefile, then it runs make to echo out the expanded values
of the X Imakefile variable values, and uses them to set x_includes and
x_libraries.
The problem here of course is that xmkmf is a host tool, which is being run
directly (i.e. no macro to override), and will always return paths valid on the
host. Which is wrong for a cross compiler. Though I suppose we could try
overriding the _AC_PATH_X_XMKMF function itself.
I only took a quick look at this, so I don't know why this is breaking for some
and working for others. Perhaps it matters whether you have X headers and
libraries in your sysroot. Perhaps it matters whether you use a sysroot. It
clearly does matter whether you have xmkmf installed on your host machine. If
you don't have xmkmf installed (which is part of the imake package), then you
presumably won't have this problem.
--
wilson at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilson at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
