The 68k/Coldfire Update

Tue Jan 21 07:41:37 UTC 2003

Hello Dan,

I think this is a good "real life" description for how to 
update... Just one hint for all: I also have different 
versions of certain tools (autoconf, automake etc.) especially 
for RTEMS. Whenever I work for RTEMS, I "source" a small 
script that changes my program search PATH to look into 
/opt/rtems/bin first. The "RTEMS"-versions of 
autoconf/automake etc. are installed there, so these tools are 
used and the older versions installed are ignored.

With this you don't have to modify any symbolic links or so. 
And even multiply people could work on the same machine with 
different projects.

wkr,
	Thomas.

> 
> 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.  I was ready
> to update linux, but Joel said that building the tools wasn't
> too hard.
> 
> 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.  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.
> 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.
> 
> Then I downloaded the source for the tools from ftp.rtems.com.
> Used the "bit" script to build them.  Went smoothly.  "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.
> 
> Then I got all the stuff for gdb 5.2.  I also needed the bdm
> patch.  Aaron Grier was very helpful with the 5.0 - 5.2 bdm
> changes.  The bit_gdb script needed a tweak for building the
> bdm version, or you could just configure and build manually.
> Remember to use the --target=m68k-bdm-rtems option for
> configure.  I don't know what all the gdb patches are for, but
> I threw them in.  You do need the 5.0 bdm driver with gdb 5.x.
> 
> 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. Go to the
> bsp directory and run bootstrap.  The bootstrap script had to
> be fixed to use the AUTOCONF (and other) environment variables
> properly.
> 
> A few things moved to different directories, library names
> changed, etc.  Nothing serious, but usually not found until
> some compile/link fails.
> 
> Then to rebuild the top-level stuff, which is C++.  The
> biggest problem is changes to the "string" type.  It's not in
> the global namespace any more, so "using namespace std;"
> boilerplate has to be inserted where necessary.  The compiler
> also complains about old xxxxx.h headers, but works ok (for
> now).  None of this is specific to RTEMS, though.  I just
> added the new stuff, like *(.jcr) to linkcmds because it
> works.  Also make-cxx-exe needs to be set in
> make/custom/<bsp>.cfg, and fix the Makefile to use it.  Then
> g++ will do the linking.
> 
> Then I got greedy and decided to gather some 2.95.x patches
> and put them into 3.2.1.  These include (1) hardware divide
> and (2) floating point (courtesy Wayne Deeter) improvements
> for coldfire.  The option -m5206e accesses hardware divide,
> because that's what I'm using.  This step took quite some
> time.
> 
> The above description is sanitized for your protection.  There
> were many false starts.
> 
> Anyway, my application program works and doesn't crash any
> more.  Patches available, YMMV.
> 
> Hope this is helpful.  If there is something stupid I've done
> (more likely) please let me know.
> 
> 
> -- 
> Dan Smisko
> Balanced Audio Technology
> 800 First State Blvd.
> Wilmington, DE  19804
> (302)999-8855
> (302)999-8818  fax
> dan at balanced.com
> 

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_keys.htm