[gccsdk] Porting scripts miscellanea

Peter Naulls peter at chocky.org
Tue Jul 31 15:15:29 PDT 2012

On 07/31/2012 02:29 PM, John Tytgat wrote:
> In message <20120731002849.GL310 at chiark.greenend.org.uk>
>            Theo Markettos <theo at markettos.org.uk> wrote:

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

config.guess is only used sometimes, or uses the package's version,
which is why you didn't see it break much/at all.  Every package
builds slightly differently.

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

It made sense 10 years ago.  Maybe now it should have a different
value.  Certainly in some projects (especially those not using
autoconf), it needs to be something else.

>> 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 :-)

I think that's ok, just make certain you really are picking up the host

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

Yes, the gnulib stuff often requires knowledge of Unixlib FILE internals
so can be a bit tricky to get right.  Avoid if possible, but putting
in UL if you need to implement them is probably ok.

More information about the gcc mailing list