[OE-core] [PATCH 8/8] gcc: enable multilib for target gcc

[Richard Purdie]

On Thu, 2012-03-15 at 02:47 +0000, McClintock Matthew-B29882 wrote:
> On Wed, Mar 14, 2012 at 9:02 PM,  <nitin.a.kamble at intel.com> wrote:
> > +    multilibs = d.getVar('MULTILIB_VARIANTS', True)
> > +    target_arch = d.getVar('TARGET_ARCH', True)
> > +
> > +    gcc_target_config_files = {
> > +        'x86_64'      : ['gcc/config/i386/t-linux64', 'gcc/config/i386/t-linux'],
> > +        'i586'        : ['gcc/config/mips/t-linux'],
> > +        'mips'        : ['gcc/config/mips/t-linux64', 'gcc/config/mips/t-linux'],
> > +        'ppc'         : ['gcc/config/rs6000/t-linux64'] }
> > +
> > +    gcc_header_config_files = {
> > +        'x86_64'      : ['gcc/config/i386/linux64.h'],
> > +        'i586'        : ['gcc/config/mips/linux.h'],
> > +        'mips'        : ['gcc/config/mips/linux64.h', 'gcc/config/mips/linux.h'],
> > +        'ppc'         : ['gcc/config/rs6000/linux64.h', 'gcc/config/rs6000/linux.h'] }
> > +
> > +    if target_arch not in gcc_target_config_files:
> > +        bb.warn('gcc multilib setup is not supported for TARGET_ARCH=' + target_arch)
> > +        return
> > +
> > +    gcc_multilib_target_config_files = gcc_target_config_files[target_arch]
> > +    gcc_multilib_header_config_files = gcc_header_config_files[target_arch]
> > +
> > +    ml_list = ['DEFAULTTUNE']
> > +    if multilibs != '':
> > +        for ml in multilibs.split(' '):
> > +            ml_list.append('DEFAULTTUNE_virtclass-multilib-' + ml)
> 
> What about adding non-multilib variants? I want to make one toolchain
> for ppce500v2, ppce500mc, ppce5550, and ppc64e5500?
> 
> Also, somehow, should we enforce all "toolchains" are built through
> this multilib build process such that I only need to configure things
> properly and then theoretically I can make a toolchain ONCE that
> supports all desired targets? E.g. I don't think we want references to
> DEFAULTTUNE since I don't want the DEFAULTTUNE to matter? Does this
> make any sense?

Whilst I understand the desire, this is not what the patch series is
intended for and I don't think it reasonable to try and change the patch
series to fit that requirement.

The big issue you face trying to do the above is iterating over the
toolchain building libgcc and libc for each of the variants you mention.
This is particularly hard since at least in the multilib case they have
different libdir paths, in your non-multilib case, they would overlap.

So no, I don't think its possible to do what you describe in this
context.

Cheers,

Richard