Re: [gccsdk] Porting scripts miscellanea

In message <20120731002849.GL310@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:

> 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

Oh, I never realized we had an arm-unknown-riscos entry in config.guess.
Something which Nick apparently did around the time he resigned from the
GCCSDK project. Nice.

Note that config.guess is actually only useful for determining the *build*
target name so in principle this entry is irrelevant unless you want to
configure and do the build on RISC OS itself. Proper cross-compiling
is done via passing --host=arm-unknown-riscos to configure.

However our porting tools are actually faking so many things that it,
intentionally, looks like we're doing a native RISC OS build with
autobuilder (but we aren't of course). Hence, all the hacks like having
a gcc softlink to arm-unknown-riscos-gcc etc.

I'm just wondering if it wouldn't be useful to disable most of the
porting-tools hacks on a per-autobuilder-project based basis for those
projects properly supporting cross-compiling...

Anyway, for this particular problem, it looks to me this is a very old
problem (first uname implementation in Feb 2005 already returned armv4l)
so I'm curious to know how did you come this across ?

I guess 'uname -m' returning armv4l is actually right (can someone ack this
on real Linux ARM setup ?), so any config.guess needs fixing (perhaps as
part of ro-config ?). I believe this can be tricky as config.guess is
not part of the package sources but gets created by the autotools (e.g.
autoreconfig).

> 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.

I like the GCCSDK_HOSTCC etc approach. Feel free to make that change.
There are several autobuilder patches using /usr/bin/gcc and that can
be fixed now :-)

BTW, be convinced that the `which gcc` is always returning the host gcc
during building (i.e. is ro-path always called with a PATH *not* containing
GCCSDK_INSTALL_ENV directory ?). If not, perhaps a better approach is to
do `which gcc` in install-env and substitute a new GCCSDK_xxx variable
during porting tools installation (like GCCSDK_BIN and GCCSDK_BUILD are
substituted).

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

You're sure ? gzip 1.2.4 doesn't mention freadahead. Or is this because
of the Debian patches ?

> /* 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.

AFAICS freadahead is a gnulib function and not implemented in glibc so
if we really are going for a gzip version with freadahead usage, it might
perhaps be better to port gnulib assuming that's reasonable work.

If freadahead is part of the Debian patches, perhaps consider to undo
those patches ?

I rather let UnixLib be a collection of standard C runtime functions
with additional glibc GNU extensions (for useful ones). gnulib
functions are a step beyond that and that can remain a separate library.

Also any freadahead implementation will make use of internal FILE data
so that looks unavoidable...

John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven

_______________________________________________
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