Re: Configure tries to run cross-compiled programs (when building crossgcc under cygwin)

[Dan Kegel <dkegel at ixiacom dot com>]

Dan Kegel wrote:
> > The script works fine on Linux, but fails on Cygwin.
> > One suspicious difference is in gcc-build-ppc405/powerpc-linux/config.cache
> > :
> > in Linux, it has
> >  ac_cv_prog_cc_cross=${ac_cv_prog_cc_cross=yes}
> > but in Cygwin, it has
> >  ac_cv_prog_cc_cross=${ac_cv_prog_cc_cross='no'}
> > Now if only I could figure out gcc's configure system...
> > I have no idea what is creating that setting.
It's libiberty/configure.  Looks like this has been a known
issue for some time; most gcc subcomponent configures
work around it, but gcc3.0.2's libiberty seems to
still misbehave.  Looking at the latest version in cvs,
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/configure.in?rev=1.52
it looks like it still calls AC_PROG_CC_WORKS.  And
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libiberty/configure?rev=1.52
shows the problem lines; look for
  # If we can't run a trivial program, we are probably using a cross compiler.

I don't think overriding
  ac_cv_prog_cc_cross=yes
will help, as that value looks like it's recomputed unconditionally.

libiberty also lives as part of binutils, and that code has the same 'bug',
but it's not a problem there, as binutils builds local executables,
not target library code.

Assuming all the consumers of ac_cv_prog_cc_cross in gcc are producing
library code, a workaround might be to just hack the configure in
fastjar, gcc, and libiberty to always say 'yes'.  But what if
gcc and fastjar need ac_cv_prog_cc_cross to say 'no', and
libiberty, libstdc++-v3, and zlib all need it to say 'yes'?
Aren't they all using the same config.cache file?

That sounds like a hard to solve problem...

- Dan


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com