Using non-rtems gcc for NIOS2 port

[Joel Sherrill <joel.sherrill@OARcorp.com>]

Waschk,Kolja wrote:

>Hi;
>
>I'm currently compiling my (basic, not yet published) port of RTEMS for
>Altera's NIOS2 processor using the original tools provided by Altera, i.e. a
>nios2-elf-* toolchain based on gcc RTEMS with a (non-RTEMS) newlib-1.12.
>
>Because the NIOS2 target is not in the official FSF gcc source tree and I
>still haven't got any comment from Altera about the future of this, I
>decided it would be nice to let people use just what's there with the
>appropriate options.
>
>However, this way it's not a simple "./configure && some extra && make
>install", because some extra options have to be specified. Maybe you have
>ideas how the following workarounds could be avoided (or beautified):
>
>1.
>
>I want to compile newlib and rtems for --target=nios2-rtems, but all the
>tool names are prefixed nios2-elf- and wouldn't be detected during
>./configure for --target=nios2-rtems, neither in newlib/ nor rtems/. I
>now have it working with definitions of all tool names in the calling
>environment, such as
>
>  OBJDUMP_FOR_TARGET=nios2-elf-objdump
>
>and I had to add all these (LD|NM|OBJDUMP|..., 9 new options) to
>rtems/acinclude.m4 so that configure actually passes them down in target
>build directories. That looks somewhat inelegant.
>
>  
>
You can probably get by by symlinking nios2-elf-XXX to 
nios2-rtems4.7-XXX for
the binutils.  gcc will require a different approach.. see below.

>2.
>
>For ./configure in rtems/, several options have to be specified as
>CFLAGS_FOR_TARGET to make sure that my rtems-specific version of newlib is
>used instead of the one built with the compiler. Cut&pasted that part of my
>build script looks like
>
>export CFLAGS_FOR_TARGET="-nostdinc\
> -isystem $PREFIX/$TARGET/include -isystem $GCCDIR/include \
> -B$PREFIX/$TARGET/lib/ -B$PREFIX/$TARGET/lib/$TARGET/$GCCVER \
> -msys-lib=c -msys-crt0=$PREFIX/$TARGET/lib/crt0.o \
> -DSYSTEM_BUS_WIDTH=32 -D__rtems__ -D__USE_INIT_FINI__"
>
>  cd $BUILD-rtems
>  $RTEMS/configure  \
>    --target=$TARGET  \
>    --prefix=$PREFIX  \
>...
>
>Ideally, configure should detect the situation itself and add the proper
>ptions for the nios2 situation (as good as possible).
>
>  
>

You are basically hacking around not having a proper binutils and gcc port.
We "fixed" binutils with symlinks.

Write a wrapper for nios-elf-gcc named nios2-rtems4.7-gcc and address 
the issues your export handles in there.

Since the assumption is that eventually you will have/create a real gcc 
and binutils port to RTEMS,  this minimizes the damage inside RTEMS.   
If you were not using GNU tools, I would be more interested in 
discussing modifications to RTEMS but these are just short term hacks 
and we need to keep them outside RTEMS.

>Comments and ideas welcome. I may have overlooked some magic
>"--prefix-for-target-tools" option ;)
>
>If, OTOH, everyone says it's okay to go with the need for a special build
>script when you want to build nios2-rtems, then fine ...
>
>  
>
For now, if the assumption is that you install the nios2-elf toolset and 
then layer on your symlinks and gcc/g++wrapper scripts, it is OK.  Not 
great and not acceptable long term.  But a lot of that is outside your 
control.  Then use those to compile the correct newlib version for RTEMS 
-- I think this much is inside your control.  I hope this minimizes the 
damage to RTEMS and lets you use RTEMS CVS with your new port.

I repeat, this is a mediocre solution but lets you ignore binutils, gcc, 
and gdb and focus on newlib and RTEMS. 

--joel

>Kolja
>
>  
>