[OE-core] [PATCH 1/8] multilib: Add support for compiling recipes against multiple ABIs

Richard Purdie richard.purdie at linuxfoundation.org
Mon Aug 1 17:00:45 UTC 2011


On Mon, 2011-08-01 at 17:30 +0100, Phil Blundell wrote:
> On Tue, 2011-07-26 at 22:53 +0100, Richard Purdie wrote:
> > +MULTILIBS ??= "multilib:lib32"
> > +BBCLASSEXTEND_append_pn-linux-libc-headers = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-eglibc-initial = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-eglibc = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-libgcc = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-gcc-runtime = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-libtool-cross = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-zlib = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-binutils-cross = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-gcc-cross-initial = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-gcc-cross-intermediate = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-gcc-cross = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-busybox = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-update-rc.d = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-util-linux = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-gettext = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-bash = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-ncurses = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-expat = " ${MULTILIBS}"
> > +BBCLASSEXTEND_append_pn-eglibc-locale = " ${MULTILIBS}"
> 
> What's the significance of this set of package names?  I couldn't
> immediately spot an obvious reason why these particular recipes were
> getting special treatment.
>  
> It seems particularly weird to have update-rc.d in there since that is
> an allarch recipe and (one hopes) isn't going to change much under
> multilib.

It was the basic testing set of things we'd tested with multilib. We
still need to better handle "all" arch, likely by adding in some
RPROVIDES and disabling the class extensions themselves.

Its intended this list go away in time and the extentions work with any
recipe and this is purely a transition artefact.

Cheers,

Richard





More information about the Openembedded-core mailing list