On Thu, 2012-03-15 at 02:47 +0000, McClintock Matthew-B29882 wrote: > On Wed, Mar 14, 2012 at 9:02 PM, <[email protected]> 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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
