libf2c cross-compile doesn't

[Chris G. Demetriou]

I've run into a problem trying to cross-compile libf2c for a mips
target using newlib from a host system running solaris 2.6.

host and cross compiler are both gcc 2.95.2 (with a few local
additions to match new target names, etc.)

i'm configuring/building in a directory outside the source directory.


the error message from the libf2c configure is:

checking f2c integer type... configure: error: Can't run check for
integer sizes -- see config.log


config.log says:

configure:1065: checking f2c integer type
configure:1087: /home/cgd/proj/systemsw/tools/build/targetbuild.20000425.0911.38/gcc-pass2/gcc/xgcc -B/home/cgd/proj/systemsw/tools/build/targetbuild.20000425.0911.38/gcc-pass2/gcc/ -B/tmp/foobar3/mips64-xxx/bin/ -c -g -O2 -DHAVE_CONFIG_H -DIN_GCC -I/home/cgd/proj/systemsw/tools/src/gcc/libf2c/../gcc/f -I/home/cgd/proj/systemsw/tools/src/gcc/libf2c/../gcc -I/home/cgd/proj/systemsw/tools/src/gcc/libf2c/../include -I/home/cgd/proj/systemsw/tools/src/gcc/libf2c/../gcc/config -I/home/cgd/proj/systemsw/tools/build/targetbuild.20000425.0911.38/gcc-pass2/gcc  conftest.c 1>&5
In file included from /home/cgd/proj/systemsw/tools/src/gcc/libf2c/../gcc/f/system.j:25,
                 from /home/cgd/proj/systemsw/tools/src/gcc/libf2c/../gcc/f/proj.h:32,
                 from configure:1079:
/home/cgd/proj/systemsw/tools/src/gcc/libf2c/../gcc/system.h:133: strings.h: No such file or directory
configure: failed program was:
#line 1078 "configure"
#include "confdefs.h"
#include "proj.h"
#define FFECOM_DETERMINE_TYPES 1
#include "com.h"
int main() {

; return 0; }



As far as I can tell, this would be because the host configuration
information defines STRING_WITH_STRINGS, causing both string.h and
strings.h to be included.

The target environment, of course, doesn't actually _have_ strings.h
(since that's not provided by newlib).

If I touch "strings.h" in the target include directory, libf2c
configures and builds, at least.  (I'm having issues with the built
library, but that may be entirely unrelated.)


Any ideas on the correct way to work around this problem?  (I can't
imagine that having host configuration information used by the target
library can result in anything positive... 8-)