The 68k/Coldfire Update

[Ralf Corsepius]

On Tue, 2003-01-21 at 03:10, Dan Smisko wrote:
> I have just gone down the update road for the 68k, from
> rtems4.5.0/gcc2.95.2/autoconf2.13/automake1.4 to the latest
> snapshot and tools, all from source.  So for anyone
> contemplating this step, this may help you avoid some trouble.
> 
> My program was crashing, and I couldn't figure out why.  So,
> let's update.  I downloaded the latest rtems snapshot, and
> autoconf and automake start spitting out errors.  And so did
> g++.  Oh boy.  New tools.  I have a 2.2.14 kernel, and the
> binary rpm's all needed new libc, etc, etc, etc. 
Which OS are you on?

Why didn't you rebuild the src.rpm if your OS is too incompatible to
what Joel uses?

It would have been at least one magnitude simplier and at least 2
magnitudes safer for your host system than trying to configure from
source (There is a very high risk at accidentially corrupting your
system.

> I was ready
> to update linux, but Joel said that building the tools wasn't
> too hard.

rpm --rebuild xxxx.src.rpm
rsp. 
rpmbuild --rebuild xxxx.src.rpm

Afterwards install the rpm 
rpm -U xxx.i386.rpm

Then continue.

> First I got the latest automake and autoconf from gnu and
> installed them, because they were needed for configuring rtems
> and the bsp. I configured them as m68k-rtems-autoconf, etc.,
> and put them in /opt/rtems/bin so they wouldn't collide with
> the old versions on the system. 
##:-() Absolutely unnecessary, worse ... it's wrong.

<target>-prefixed tools are meant to be cross-tools. The autotools are
host tools, not cross tools.

Furthermore, there are good reasons why we don't do this, and install to
a separate installation prefix ( --prefix=/opt/rtems), and recommend
users to prepend /opt/rtems/bin to $PATH instead trying to outsmart the
autotools and the gnu-toolchain by playing tricks with prefixes.

More, automake-1.7.2 can be installed in parallel to other versions of
automake without any prefixing or postfixing tricks.

Achieving the same behavior for autoconf is much more difficult and
requires patching autoconf (not even the version RedHat ships with
RH-8.0 gets it right).

=> I don't recommend what you did.

>  Then I would set AUTOCONF,
> etc.  variables when I needed to use the new stuff.  It turns
> out that a newer (than 4.0) makeinfo was needed for gcc docs.

This is a gcc-FAQ - Also, makeinfo-4.0 is several years old and far from
being new.

> However, configure ignores MAKEINFO. So you have to make a
> link to m68k-rtems-makeinfo, or whatever, if you want to keep
> your old stuff.
Same remark as above: makeinfo is a host tool. Applying
<target>-makeinfo is a fault.

Further, I think your installation is broken. gcc/newlib/binutils build
using "makeinfo"


> Then I downloaded the source for the tools from ftp.rtems.com.
> Used the "bit" script to build them.

Bit is dead - Using it is discouraged.

>   Went smoothly. 
I am more than surprised - Which host compiler did you use. 

m68k-rtems-gcc is known not build for certain newer host-gcc's.


>  "Getting
> Started" describes this pretty well.  You don't need any of
> the new autoXXXX stuff for this step.  I changed "bit" a
> little to suit me.
You don't even need the auto*tools for building RTEMS ;9

You only need them for working on RTEMS.

> Next was moving configure.ac and Makefile.am for the bsp and
> some library code.  I am NOT an expert in autoconf and
> friends, so this was not fun.  Fortunately, the other m68k
> stuff provided enough examples.  There was much cursing, and
> this turned out to be the most time-consuming part.

> Acinclude.m4 in the m68k directory has to be changed to
> include the bsp, then run $AUTOMAKE and $AUTOCONF.
This is a known problem.

>  Go to the
> bsp directory and run bootstrap.  The bootstrap script had to
> be fixed
Correction: Hacked ;)

>  to use the AUTOCONF (and other) environment variables
> properly.
If you had used a separate prefix to install RTEMS you would not have
had any of these problems.

> Hope this is helpful.  If there is something stupid I've done
> (more likely) please let me know.

See above.

Ralf