Prerequisites for building crosstool-NG and tool chains

[theNbomr]

I am trying to use a couple of different Redhat (EL4.x & EL5.x)
platforms for running crosstool-NG (trying 1.4.1, and 1.5.1). Running
'configure --local' produces problems with (at least) bash and automake
version requirements.
Are the minimum requirements set forth in 'configure' actual hard
requirements, or can I relax the requirements and still get a successful
  build? It is difficult for me to upgrade system tools on an ad-hoc
basis, as these hosts must be kept in a state that is well understood
and easily restorable. Changes to basic distribution configurations are
strongly discouraged.
On a similar note, is there a preferred host distribution platform for
running crosstool-NG? As an experiment recently, I found that on a
recent distribution of Open Suse, I was able to install and run
crosstool-NG without updating anything on the host. I haven't tried the
built toolchain yet, but at least I was able to create one without headache.
Has anyone used a distro installed as a virtual OS, simply as a host
system for running crosstool-NG? What configuration did you use? How
successful/easy/difficult was it?
My present target architectures are ARM (for TS-7350 SBC), and x86 (for
VME based Pentium CPUs). Anyone have a working .config file for either
of these target platforms?
Is there any intention that older releases of crosstool-NG should
continue to work? I found that one 1.4.X version that I had previously
used would no longer build a toolchain, because it could not download a
source package from the net. Is this an expected behavior, or should I
expect the download problem to be a temporary network issue?

Thanks to Yann, and to everyone else who has contributed to this
valuable tool.

    ---   rod.


--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Yann E. MORIN]

Helo Rod,
Hello All!

On Friday 30 October 2009 18:02:23 Rod Nussbaumer wrote:
> I am trying to use a couple of different Redhat (EL4.x & EL5.x)
> platforms for running crosstool-NG (trying 1.4.1, and 1.5.1). Running
> 'configure --local' produces problems with (at least) bash and automake
> version requirements.
> Are the minimum requirements set forth in 'configure' actual hard
> requirements, or can I relax the requirements and still get a successful
>   build?

bash-3.1 or above is an absolute requirement: crosstool-NG heavily relies
on features that appeared in bash-3.1. I would very much like to use 4.0,
as it has very compeling features, but it is not widely-enough deployed.
Even 3.2 would be nice, but even this now-ageing version is not widely
available on many systems (heck, a server that's been deployed 4 years
ago may still have a bash-2.05b!).

As for automake, crosstool-NG does not use it by itself, but some components
(eg. giunutils, glibc, gcc...) do require automake, and automake 1.10 was
found to be the strictly minimum requirement in some situations, hence it
is a hard requirement.

Other tools required by crosstool-NG's ./configure follow the same rule.

>   It is difficult for me to upgrade system tools on an ad-hoc  
> basis, as these hosts must be kept in a state that is well understood
> and easily restorable. Changes to basic distribution configurations are
> strongly discouraged.

I can understand, yes. This is an issue. Having crosstool-NG build its
requirement might not even be a solution in that case.

> On a similar note, is there a preferred host distribution platform for
> running crosstool-NG? As an experiment recently, I found that on a
> recent distribution of Open Suse, I was able to install and run
> crosstool-NG without updating anything on the host.

I'm using a Debian Lenny, following updates on a regular basis. It has
been found to work on recent Fedora Core, on recent openSUSE. It works
on Ubuntu 804LTS server. Also, Cygwin (but that is discouraged due to
the high penalty incurred by the POSIX-over-Win32 emulation layer).

> I haven't tried the
> built toolchain yet, but at least I was able to create one without headache.
> Has anyone used a distro installed as a virtual OS, simply as a host
> system for running crosstool-NG? What configuration did you use? How
> successful/easy/difficult was it?

I'm (seldomly) using an x86 Ubuntu 804LTS, on an x86_64 qemu (with kvm
support), on an x86_64 Debian Lenny, on an x86_64 CPU with VT extensions.

Although qemu emulates SMP systems, it does not use the physical multiple
CPUs, so you are basically limitted to a UP system in qemu. If you seldom
build toolchain, that's not an issue. If you need to build many (to search
for, and fix an issue), then that will be a problem.

You may want to look at VirtualBox an dsee if it can levrage physical SMP
to emulate an SMP system...

> My present target architectures are ARM (for TS-7350 SBC), and x86 (for
> VME based Pentium CPUs). Anyone have a working .config file for either
> of these target platforms?

Look at the sanples (ct-ng list-samples) and tweak the one nearest to your
needs.

> Is there any intention that older releases of crosstool-NG should
> continue to work?

Depends. Crosstool-NG by itself should continue to work. There is maintenance
for each 1.x series, until the 1.(x+1).0 goes out, in which case the 1.x
series is no longer maintained, and the 1.(x+1) is maintained, and so on...

Given the same input (same .config, same tarballs, same host), crosstool-NG
should reproduce the same output (minus timestamping). If any input changes
(eg. missing tarball from upstream), then... :-(

> I found that one 1.4.X version that I had previously  
> used would no longer build a toolchain, because it could not download a
> source package from the net. Is this an expected behavior, or should I
> expect the download problem to be a temporary network issue?

If things are going MIA on the net, then there is nothing crosstool-NG
can do to work around this... At least, crosstool-NG offers you the
possibility to store the downloads in a place they can be retrieved
later on. That's what "Local tarballs directory" and "Save new tarballs"
are for.

> Thanks to Yann, and to everyone else who has contributed to this
> valuable tool.

Thank you! :-)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| [phone] | Software  Designer | \ / CAMPAIGN     |  ___               |
| [phone] `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq