Building RTEMS. Targets and overrides...

[Ralf Corsepius]

On Thu, 2005-08-04 at 16:34 +0200, Per Dalgas Jakobsen wrote:
> >>I'm trying to build RTEMS-4.6.2 on a Cygwin host for a Pentium target.
> >>I have successfully made a cross-toolchain for i586-rtems: 
> >>binutils-2.16.1, newlib (CVS from yesterday) and gcc-3.4.4
> > 
> > Are you sure you did? How did you configure the toolchain?
> 
> By successfully, I meant no compilation errors, and is able to compile a 
> small program with:
That's not what I wanted to know. I had wanted to see the command line
you passed to binutils and gcc's configure scripts.

> i586-rtems-gcc -v -S <small program> (and the assembler looks fine).
> and
> i586-rtems-gcc -v -c <small program>
> But I really don't know if it *works* (since I have no RTEMS to test it 
> out on yet).
> 
> binutils: configure --prefix=$PREFIX --target=$TARGET --enable-libada
> 
> gcc-newlib: configure --prefix=$PREFIX --target=$TARGET --with-gnu-as 
> --with-gnu-ld --with-newlib --enable-threads --enable-libada 
> --disable-nls --enable-languages=c,ada


> >>Unfortunately it seems not so easy to configure RTEMS for an 
> >>586-optimized toolchain/compiler.
> >>
> >>Any good reasons for that?
> > 
> > Yes, because it doesn't make much sense.
> > 
> > i586 is treated as a cpu variant of the i386 architecture (some call
> > this the "base architecture"), i.e. as 
> > "i386-rtems-gcc -mtune=pentium"
> 
> Then why not streamline it so i586 is working as expected?
What streamlining are you talking about? There is no such thing.

SuSE uses i586-*, RH uses i386-*, while they internally actually use
i486, cygwin uses i686, others might use other defaults.

We use the base architecture of the i386 family and that inside of GCC
is "i386".

Also, i386/ix86-based Linux distros typically are not multilib'ed. The
RTEMS toolchains are. I.e. we build several of the toolchains at once,
which users (e.g. you) can switch between at build-time, i.e. this
offers you more flexibility than you normally probably need, but which
might be helpful to you in some cases (e.g. for debugging
code-generation issues), and helps us to avoid having to maintain 100's
of toolchains.

> Is that hard to do?
It's not that hard, but problems are lurking in detail. I really don't
know if an i586-rtems-gcc is functionally at all, because nobody has
tested it. 

> >>Then I tried
> >>* configure --prefix=/opt/i586-rtems --target=i386-rtems 
> >>--program-prefix=i586-rtems- --disable-cxx --enable-rtemsbsp=pc586 
> >>--disable-itron
> >>
> <snip>
> >>"checking for i386-rtems-strip... no" - Strange... I asked to look for
> >>i586-rtems-<tool>.
> > 
> > No, you used --target=i386-rtems, i.e. you asked it to look
> > for i386-rtems-<tool>.
> 
> Yes, but I explicitely asked it to prefix all tools with 
> "--program-prefix=i586-rtems-"... But it doesn't seem to honour that.
Yes, we don't honor it, because its meaning is unclear in general (Is it
supposed to be the prefix of the tools to be used or the prefix being
prepended to tools being installed, and how does it interact with
--program-suffix, rsp. --transform-name) and conflicts with other
conventions on cross compilation (is it the prefix of the host, build,
or target tools?).

> Perhaps I misunderstood something here?!?
I think so. 

Unless you hit a bug in binutils or gcc, configuring both with
--target=i586-rtems should do what you want.

Ralf