On Tue, May 20, 2014 at 09:23:22PM +0100, John Tytgat wrote:
> For building gccsdk, we used to be sensitive to distro flavors because
> gcc/binutils really require exact autotool versions which were then taken
> from the host. That was unpredictable and sometimes required manually
> installing the right versions. Currently we're building the required
> autotools versions ourselves and that solved those gccsdk building issues.
>
> However, for the Autobuilder, some packages do autoreconf (or something
> similar to recreate the autotools files) and that still takes the autotools
> versions installed on the host which makes building with Autobuilder
> unpredictable. We could do the same thing as gccsdk, building the
> required autotool version needed for those packages.
I'm of the opinion that VMs are cheap, so trying to make a setup that will
have the least hassle, with whatever OS necessary. Your plan sounds like a
good idea. In the meantime, if I pick Debian wheezy and install all the
auto{conf,make}x.xx packages, will the autobuilder handle using the right
ones?
(It's a VM, so would rather not use a GUI distro that drags in GNOME et al
and gets confused when starting X since there's no video card)
In message <537bab40.6080...@sky.com>
Lee Noar <leen...@sky.com> wrote:
>
> If I'm reading the
> fetch-program script correctly, it looks in testing (jessie) first and if it
> doesn't find the package there, falls back tostable (wheezy).
Given that 'testing' is a moving target, is it better to stabilise on
something? Has recent package updating work (Alan, Lee, Chris?) been using
the default sources (ie 'testing')?
There was a suggestion some time ago of standardising on Ubuntu (since it
has LTS releases), but again I prefer to take the least hassle option - so
if packages are optimised for Debian sources it would seem to make sense to
use that. Standardising on Debian stable/wheezy is another option (since
many of the packages were probably last updated when 'wheezy' /was/ testing
- or before).
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
