problems with upgrade to latest tools

Tue Dec 31 15:08:40 UTC 2002

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Gregory,

thanks for your help. Do you also have the problem that linking stops
after building the exe file?
Have you changed anything in your makefiles to fix this?

Peter

On Tue, 31 Dec 2002 10:40:50 -0500 (EST)
gregory.menke at gsfc.nasa.gov wrote:

> 
> 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.
> 
> ============================================================
> 

- -- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+EbL0UzCcwYQMTJoRAnS3AKCexDWXPAywql6/F6y2q8IzexaGEwCgmkHl
NxttTC/fTBlVJtIoBOyuJXE=
=EjyY
-----END PGP SIGNATURE-----