Re: [gccsdk] Porting scripts miscellanea

On Tue, Jul 31, 2012 at 11:29:50PM +0200, John Tytgat wrote:
> 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...

That might be nice. But I remember that back before we had the
porting-tools hacks I would spend a very long time hacking autoconf files
that weren't expecting cross compilation. The most painful one was tetex
(an entire TeX distribution) - this compiles a toolchain (web2c, kpse), then
uses that to compile the compiler (TeX, LaTeX, etc), then uses the compiler
to compile the library files (fonts, packages, etc). Things like that
aren't designed for cross-compilation and even the porting-tools hacks fall
over eventually. I never got around to trying such a build with qemu user
mode emulation, which might have allowed it to run RISC OS executables under
Linux which would probably have been the only way it would work.

But might be useful for those few packages that actually behave.

> 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 was trying to fix libglib-2.0, which uses a tool glib-compile-resources.
That isn't available in Ubuntu 11.04, so I compile glib natively, install to
$GCCSDK_INSTALL_CROSS (newly defined to be $GCCSDK_INSTALL_CROSSBIN/../),
make clean, then standard compile with the porting-tools. After all that
palaver, it falls over at configuration due to config.guess giving up.

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

My Raspberry Pi says:
uname -m: armv6l
uname -p: unknown
uname -i: unknown
uname -o: GNU/Linux
uname -s: Linux

If that's correct I suggest we push a change into config.guess' upstream
git, and then have something in porting-tools that fixes up any
config.guesses that we find without that. Eventually the change will
propagate through upstream maintainers, but it'll take a few years.

I have an addition to ro-config to do this, which seems to work.

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

Turns out the ro-config already has HOST_CC etc for the benefit of autoconf.
So I added that to ro-path too, like this:

if [ -z "$GCCSDK_HOST_PATH" ] ; then
export HOST_CC=$(which cc)
export HOST_CXX=$(which c++)
export GCCSDK_HOST_PATH=$PATH
fi

That means we have the system path preserved should we need it.

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

Not sure... the system might change underneath (eg install new compiler)
which would invalidate the install-env step. I think the GCCSDK_HOST_PATH
thing avoids any problems, but there might be corner cases where it goes
wrong.

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

Ah, it might be. Haven't had a chance to look at this yet.

Oh. I haven't actually committed the above patches because I just killed my
remote build machine... one of the other changes was an AB_CPUS variable to
allow quicker builds on multicore machines, by adding -j$AB_CPUS to make
commands ... trouble is, when $AB_CPUS doesn't exist it turns into a fork
bomb. Thanks, make. I'll have to fix that ;-)

On a related note there's code for distcc in the autobuild scripts - is
there any documentation on how that's supposed to work?

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