Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c

[Jamie Lokier <jamie at shareable dot org>]

Daniel Jacobowitz wrote:
> On Thu, Jan 29, 2009 at 06:12:15AM +0000, Jamie Lokier wrote:
> > I wouldn't be surprised if the Codesourcery tools (especially
> > pre-built libs) are targetting later ARM chips only, since people
> > using later ARM chips are probably paying Codesourcery for the work.
> 
> Our tools support all (post-V4) ARM processors; I believe that we
> package libraries for all processors too nowadays.  The defaults may
> be fairly modern, though - so as Jamie said, be sure to tell the tools
> what you want your code to run on!

ARM has a huge number of instruction set variants.  This is a quick
guess, I'm no expert (but I've already been daunted when looking into
ARM FDPIC-ELF, simply at the number of different ways jumps and calls
are encoded)):

    { OABI, EABI soft-float, EABI hard-float }
                     times
    { ARMv4, ARMv4T, ARMv5, ARMv6, ARMv7 (?) }
                     times
            { not Thumb, Thumb, Thumb2 }
                     times
             { Thumb interwork or not }
                     times
         { non-PIC, PIC, PIC+single-pic-base }

Do you really have a policy of including pre-built multilib-ed libc
and libstdc++ as well as libgcc for all the combinations that make
sense?

My approach these days is to build all libraries including libgcc
specifically targetted at the CPU variant being used by whatever
projected I'm using.  It saves headaches from things that crash
spontaneously otherwise.  I haven't tried the Codesourcery ARM tools
yet, though I intended to soon.

-- Jamie