building RTEMS alone

[Ralf Corsepius]

Preliminary note: I don't know anything about lucent processors :)

Joel Sherrill wrote:
> 
> If the .h files are in INSTALLPOINT/TARGET/include then RTEMS
> will automatically see them.
> 
> The configure line by hand should be something like this:
> 
> .../rtems-XXX/configure --target=lucent16000-rtems \
>   --prefix=INSTALLPOINT
> 
> I don't know what "target" cpu you are calling the 16000.
AFAIS from poking around at lucent's www-site and into config.sub, I
think using "dsp16xxx-rtems" or "dsp16000-rtems" might be
appropriate.

> I would guess that config.sub has to be modified though.
Yep. I think tracing and extending how the dsp16xx family is treated
in config.sub is the closed possible solution. (AFAIU, the dsp16xx
family is the predecessor of the dsp16xxx family. It may also be the
case the dsp16000 is a member of the dsp16xx family :).

> 
> It sounds like you are getting past the intial configure
> steps though. :)
> 
> I hope this helps.
> 
> --joel
> 
> Ahmet Akkas wrote:
> >
> > Hi everybody,
> >
> > I am working on porting RTEMS to Lucent's 16000 DSP processor by using
> > Lucent's tools (compiler, assembler, etc.). I have already build newlib
> > library. Right now I want to build RTEMS without using bit_rtems script
> > (as you know bit_rtems build gcc and newlib together). I used bare bsp
> > option only build the kernel.
> >
> > Anyway, my question is the following:
> > I will run configure command with its options under the build directory.
> > The part I do not know is that even in the configure command, I set --includedir
> > variable to the library I want to use it, configure command it copies the
> > content of "includedir" to the Makefiles under the build directory but in
> > the compilation (it was compiling libc) it still does not include the directory
> > I specified in configure command.

In general, includedir and libdir are supposed to point to
directories were headers and libraries shall be *installed*. From
autoconf.info:
> [..]
> - Variable: includedir
>      The directory for installing C header files.
> [..] 
> - Variable: libdir
>      The directory for installing object code libraries.
[Building RTEMS does not apply these variables.]

Instead you need to set up a set of environment variables to let the
Makefiles find the libraries and header files. Try to track how
CC_FOR_TARGET, CFLAGS etc. are being setup in make/custom/<bsp>.cfg
(esp. make/custom/default.cfg and
make/compilers/gcc-target-default.cfg - Though the name
"gcc-target-default.cfg" is misleading, this file is supposed not to
be specific to gcc. It's named this way for historical reasons :). 

Something else that will ease porting RTEMS with a non-gnu toolchain
(And which I recommend to do) is to apply the gnu-toolchain's naming
conventions to the toolchain's binaries. I.e. to install a copy or
shell script wrapper of each tool (cc, as, ld etc.) of the toolchain
as <target>-tool, e.g. copy <path>/lucent/dsp16000/cc to
<somewhere>/bin/dsp16xxx-rtems-cc and make sure these can be picked
up from $PATH.

Additionally you should configure RTEMS with --disable-gcc28 to
disable building RTEMS using features which are only present in gcc
>= 2.8. Unfortunately, most actively supported RTEMS ports have only been built/tested with toolchains using gcc >= 2.8, so I would not be surprised this to trigger bugs in RTEMS configuration.

I hope this helps a little.

Ralf

-- 
Ralf Corsepius 
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999  
http://www.faw.uni-ulm.de