Re: [gccsdk] Porting scripts miscellanea

On 07/31/2012 02:29 PM, John Tytgat wrote:
> In message <20120731002849.GL310@chiark.greenend.org.uk>
> Theo Markettos <theo@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
compiler.


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







_______________________________________________
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