[OE-core] [PATCH] ppl: fix libgmp paths

Richard Purdie richard.purdie at linuxfoundation.org
Thu Dec 8 00:12:04 UTC 2011


On Wed, 2011-12-07 at 13:19 -0800, Khem Raj wrote:
> On (06/12/11 13:27), Martin Jansa wrote:
> > configure:10654: checking how to link with libgmpxx
> > configure:11127: result: /OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/libgmpxx.so /OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/libgmp.so -Wl,-rpath -Wl,/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath -Wl,/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib
> > 
> > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > ---
> >  meta/recipes-support/ppl/ppl_0.11.2.bb |    6 +++++-
> >  1 files changed, 5 insertions(+), 1 deletions(-)
> > 
> > diff --git a/meta/recipes-support/ppl/ppl_0.11.2.bb b/meta/recipes-support/ppl/ppl_0.11.2.bb
> > index 7536364..b31fc4d 100644
> > --- a/meta/recipes-support/ppl/ppl_0.11.2.bb
> > +++ b/meta/recipes-support/ppl/ppl_0.11.2.bb
> > @@ -11,6 +11,10 @@ SRC_URI[sha256sum] = "e3fbd1c19ef44c6f020951807cdb6fc6a8153cd3a5c53b0ab9cf4c4f6e
> >  S = "${WORKDIR}/ppl-${PV}"
> >  BBCLASSEXTEND = "native nativesdk"
> >  
> > -EXTRA_OECONF = "--enable-watchdog --disable-debugging --disable-assertions --disable-ppl_lcdd --disable-ppl_lpsol --disable-ppl_pips --enable-interfaces='c cxx'"
> > +# do we have something shorter then this? or can native.bbclass overwrite STAGING_DIR_HOST like nativesdk does?
> > +GMP_PREFIX = "${STAGING_DIR_HOST}"
> > +GMP_PREFIX_virtclass-native = "${STAGING_DIR_NATIVE}"
> > +
> 
> I think we should override STAGING_DIR_HOST in native class as well.
> Since we do install native packages into local sysroot before populating
> the global native sysroot. The comment in class code seems that since
> we installed the native packages in position it was needed to be unset
> that may not be the case now.
> 
> RP thoughts ?

native.bbclass already sets STAGING_DIR_HOST correctly to be empty. It
looks wrong but its correct when you think about it since the installed
binaries are at their final location where we intent to execute them (in
${prefix}).

Cheers,

Richard







More information about the Openembedded-core mailing list