[gccsdk] Porting scripts miscellanea

As a result of this evening's hacking, a few questions have arisen...

1. config.guess is failing to detect the machine because our 'uname -m' is giving
a hardcoded 'armv4l'. That is what Linux gives, but config.guess has this rule:
arm:riscos:*:*|arm:RISCOS:*:*)
echo arm-unknown-riscos
exit ;;

in other words, the machine type is plain 'arm', not 'arm' with a suffix.
Linux's rule is more flexible:
arm*:Linux:*:*)

What's odd is that config.guess's RISC OS rule hasn't changed since 2005
according to its upstream git[1], and our uname has always been like that
(created about 2004). Has it really been broken for that long? Am I being
stupid somehow?

[1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree


2. Any objections if I add HOSTCC=`which gcc` and HOSTCXX=`which g++` in
ro-path? (Or some nicer shell incantation) I don't know if this will break
other builds that know about cross compiling. The alternative is to make
them GCCSDK_HOSTCC etc. The motivation is to allow access to the host build
tools for things that need it. Because ro-path splats itself over the
system's path, there's no way to get at the host's tools. Hardcoded
/usr/bin/gcc can be used, but that's not so friendly to non-Linux systems.
Alternatively, perhaps ro-path could retain the system path in a variable.


3. gzip now wants freadahead() and won't build without it:

/* Assuming the stream STREAM is open for reading:
Return the number of bytes waiting in the input buffer of STREAM.
This includes both the bytes that have been read from the underlying input
source and the bytes that have been pushed back through 'ungetc'.

If this number is 0 and the stream is not currently writing,
fflush (STREAM) is known to be a no-op.

STREAM must not be wide-character oriented. */

extern size_t freadahead (FILE *stream) _GL_ATTRIBUTE_PURE;

I don't think there's a way to read that information from RISC OS for an
open file, but it looks like stream->i_cnt will do the trick, but I'm not
supposed to go poking around in UnixLib's internals. Is it worth
making a public API for this, and where would it go in the Unixlib
source/headers? I could always lie, of course, but I suspect this is done
for performance reasons.


Thanks
Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK