Re: [ECOS] Recommended gcc version for 1.0?

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    Grant> On Wed, Aug 06, 2003 at 04:18:22PM +0100, Nick Garnett wrote:
    >> > When did big-endian ARM gcc users become second-class citizens?
    >> > I swear that for 2.95, doing a "confgure --target=arm-elf" used
    >> > to work just fine.
    >> 
    >> This was done to keep the number of different versions of the
    >> libraries down.

    Grant> Here is where I get confused.

    Grant> What libraries?

    Grant> When I build 2.95.2 for use with eCos, the only library
    Grant> that is built is libgcc.a:

A full compiler build involves libgcc, libsupc++ & libstdc++ which are
either necessary for eCos developers or useful to a proportion of eCos
users. Then there is also newlib (libc and libm), libgloss, and
libiberty which are not useful for eCos users. In the prebuilt
toolchain tarballs we provide those have been removed (they still need
to be built because the C++ library build process expects them).

Now you need to worry about multilibs. On the processor side you have
to worry about arm7 (the default), xscale, sa1110, arm9, and thumb.
Thumb gets messy because you need to worry about thumb-only versus
interworking between thumb and arm mode. Little-endian vs big-endian
adds another bunch of permutations. Then there are older multilibs for
processors predating arm7, for various calling conventions, for
hardware vs. software floating point, and so on. Look at the gcc
documentation for all the arm-specific -m options. Not all of them
need separate multilibs, but some do.

In theory each option like thumb interworking doubles the number of
multilibs. In practise not all combinations are valid, so supporting
more options does not quite lead to exponential growth in the number
of multilibs, but it comes close.

IIRC there is an arm-elf toolchain tarball on an Intel ftp site which
is something like 50MB or 100MB, I don't remember exactly. The
eCosCentric tarball is 11.6MB, which is still a large download but
much more reasonable. To get it down to that size we had to limit the
number of multilibs to the 11 we felt most useful for typical eCos
developers. Big-endian support had to go.

As for the default settings in gcc 2.95.2 vs. 3.2.1 or later, that is
an issue for a gcc mailing list. However the number of options
requiring separate multilibs has increased significantly since 2.95.2
days, for example thumb support was separate in those days and xscale
did not yet exist.

Bart

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss