problems with upgrade to latest tools

[gregory.menke at gsfc.nasa.gov]

Peter Mueller writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Hello,
 > 
 > during looking after one bug (see earlier mail) I now have other problems
 > :-)
 > 
 > I upgraded from gcc 2.95.3 to m68k-rtems-gcc (GCC) 3.2.1 (OAR Corporation
 > gcc-3.2.1-20021209/newlib-1.10.0-20021127 4)
 > 
 > Compiling my (c++) application works fine but now I got many errors while
 > linking. First of all I found out that I need a new entry in linkcmds: 
 > *(.jcr) What is this for?
 > 
 > Then it seems that I have to link now with g++ to get rid of all the
 > "undefined ...". errors. But when I link with g++ (by the way, where can I
 > set make-cxx-exe) the usual make procedure stops after creation of the
 > *.nxe file but does not run m68k-rtems-objcopy, m68k-rtems-nm,
 > m68k-rtems-size. Why that? Do I have to change something in my makefile (I
 > have it attached)?
 > 
 > Next is: do I need a gdb version newer than 5.0 to work with gcc 3.2.1?
 > 
 > Hope you can help me, becaus my built env is broken at the moment.
 > 
 > Peter
 > 
 > P.S: The reason why I upgraded to a newer compiler was that a newer libc6
 > breaks gcc with internal errors. Maybe I can fix this by compiling gcc
 > 2.95.3 on my own. How can I do that? I'm running debain (woody) + this f*
 > libc6 from testing.
 > 

The .jcr section seems to be new with gcc 3.x.  I don't know what it
ends up doing though.  Refer to /opt/rtems/<xxx>/lib/ldscripts where
<xxx> is your architecture (m68k?), which contains the canonical link
scripts used by GNU.  It seems many of them are just loaded with
cruft, but the .jcr stuff will be there in its proper place.  The
different link scripts do slightly different things, refer to one with
the extension '.x'.  You might also need to add .eh_frame and
.eh_frame_hdr.  I've had to do this for the mongoose, jmr3904 and
motorola_powerpc bsp's.

Do you have binutils updated as well?

gdb 5 or 5.2 should work fine, but you'll have to cross-compile it or
fetch rpms for your particular target.  I've found I prefer to
cross-compile as rpms tend to cause me intractable library/symbol
problems.  I can build the full gcc/binutils/newlib cross-compiled
suite using gcc 2.95.3 on x86 Linux 2.2.x, Solaris and ppc Linux
2.2.x.

I've appended my little Cross Compiler Receipe thing we use here.  I
imagine it could be improved, but its worked OK so far.


Gregm

===File /home/posixfsw/rtems/rtems-tool-source/buildgcc.txt===

This is for gcc 2.95.x or gcc 3.x.  These procedures tested on Intel &
PowerPC Linux, cygwin on Win9x/NT/2000, and Solaris 8/9.  Building cross
compilers requires your system have a reasonable gcc suite installed.
This means gcc-2.95 or greater with its associated binutils and c
library.  Generally this is supplied by the operating system install or
some kind of a package manager.

1.  Obtain binutils, gcc and newlib sources from OAR or GNU.  Use
    recommended versions, not all work together [1].  We have been
    sucessful with;

    gcc 2.95.3, binutils 2.10, newlib 1.9, gdb 5.2 
     (local autoconf 2.52, automake 1.6.3 work)

    gcc 3.2, binutils 2.13, newlib 1.10, gdb 5.2
     (requires local versions of autoconf 2.52, automake 1.6.3; do not
	use newer versions)


2.  Untar them from one working directory, each tar file supplies its
    own necessary and sufficient directory structure.

3.  Apply patches as necessary via 'patch -p0 < [patch filename]',
    invoking it from the working directory where everything was
    un-tarred.

4.  Binutils first, cd into it.  mkdir build, cd build.  Then;

../configure --prefix=<install directory> --target=mips-rtems --verbose
make 
make install

    
5.  Add <install directory>/bin to PATH.


6.  Now gcc.  Put a symlink from the toplevel gcc directory to the
    directory 'newlib' just under the top level newlib directory, ie;

cd gcc-<whatever>
ln -fs ../newlib-<whatever>/newlib newlib

    If a symlink is impossible for some reason, copy the
    newlib-<whatever>/newlib directory and all its subdirs to
    gcc-<whatever>.

    In gcc-<whatever>, mkdir build, cd build.  Then;

***** For gcc-2.95 series ****

../configure --prefix=<install directory> --target=mips-rtems
--verbose --with-gnu-as --with-gnu-ld --with-newlib --enable-threads
--enable-languages='c,c++'

***** For gcc-3.x series ****

../configure --prefix=<install directory> --target=mips-rtems --verbose
--with-gnu-as --with-gnu-ld --with-newlib --disable-multilib
--disable-nls --enable-threads --enable-languages='c,c++'

****

make
make install


7.  For powerpc builds, the above steps and parameters are identical
    except for '--target=powerpc-rtems'.  Delete all contents of the
    binutils and gcc 'build' directories you created above before
    rebuilding gcc & binutils.  The output binaries are prefixed with
    the target, so may coexist in the same install tree.

8.  If gdb is to be built, follow the binutils instructions.



[1] - binutils/gcc toolchains are sometimes sensitive to
      automake/autoconf versions, particularly when quoting rules
      change.  Where necessary, particular version issues are indicated.

============================================================