On Sat, Feb 25, 2012 at 01:02:48AM +0000, Richard Purdie wrote:
> On Sat, 2012-02-25 at 01:05 +0100, Martin Jansa wrote:
> > On Thu, Feb 23, 2012 at 10:27:53AM +0000, Richard Purdie wrote:
> > > On Mon, 2012-02-13 at 16:40 +0100, Martin Jansa wrote:
> > > > * seems like config/config in -L was also wrong
> > > >
> > > > Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
> > > > ---
> > > > meta/recipes-devtools/gdb/gdb-cross-canadian.inc | 10 ++++++++--
> > > > 1 files changed, 8 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
> > > > b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
> > > > index b5746ce..bac63b7 100644
> > > > --- a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
> > > > +++ b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
> > > > @@ -10,12 +10,18 @@ RDEPENDS += "python-nativesdk-core
> > > > python-nativesdk-lang python-nativesdk-re \
> > > >
> > > > EXTRA_OECONF_append = "--with-python=${WORKDIR}/python"
> > > >
> > > > +NATIVESDK_NAME = "oecore-${SDK_ARCH}-${SDK_ARCH}"
> > > > +NATIVESDK_PATH = "/usr/local/${NATIVESDK_NAME}"
> > > > +NATIVESDK_PATHNATIVE = "${NATIVESDK_PATH}/sysroots/${SDK_SYS}"
> > > > +NATIVESDK_LIBDIR = "${NATIVESDK_PATHNATIVE}${libdir_nativesdk}"
> > > > +NATIVESDK_INCLUDEDIR = "${NATIVESDK_PATHNATIVE}${includedir_nativesdk}"
> > > > +
> > > > do_configure_prepend() {
> > > > cat > ${WORKDIR}/python << EOF
> > > > #! /bin/sh
> > > > case "\$2" in
> > > > - --includes) echo
> > > > "-I${STAGING_DIR}/${HOST_ARCH}-nativesdk${HOST_VENDOR}-${HOST_OS}${exec_prefix}/include/python${PYTHON_BASEVERSION}/"
> > > > ;;
> > > > - --ldflags) echo
> > > > "-L${STAGING_DIR}/${HOST_ARCH}-nativesdk${HOST_VENDOR}-${HOST_OS}${libdir}/python${PYTHON_BASEVERSION}/config/config
> > > > -lpthread -ldl -lutil -lm -lpython${PYTHON_BASEVERSION}" ;;
> > > > + --includes) echo
> > > > "-I${STAGING_DIR}/${HOST_ARCH}-nativesdk${HOST_VENDOR}-${HOST_OS}${NATIVESDK_INCLUDEDIR}/python${PYTHON_BASEVERSION}/"
> > > > ;;
> > > > + --ldflags) echo
> > > > "-L${STAGING_DIR}/${HOST_ARCH}-nativesdk${HOST_VENDOR}-${HOST_OS}${NATIVESDK_LIBDIR}/python${PYTHON_BASEVERSION}/config
> > > > -lpthread -ldl -lutil -lm -lpython${PYTHON_BASEVERSION}" ;;
> > > > --exec-prefix) echo "/usr" ;;
> > > > *) exit 1 ;;
> > > > esac
> > >
> > > I made some experiments with "bitbake gdb-cross-canadian-x86-64 -e" and
> > > it seems to me that:
> > >
> > > --includes) echo
> > > "-I${STAGING_INCDIR}/python${PYTHON_BASEVERSION}/" ;;
> > > --ldflags) echo
> > > "-L${STAGING_LIBDIR}/../python${PYTHON_BASEVERSION}/config -lpthread -ldl
> > > -lutil -lm -lpython${PYTHON_BASEVERSION}" ;;
> > >
> > > should work ok here?
> >
> > No it's not the same.
> >
> > With default oe-core settings it behaves like this:
> >
> > python-nativesdk is staged in the same directory for all 3 MACHINEs I
> > was using for test (qemuarm, qemux86, qemux86-64)
> >
> > SDKMACHINE=i686:
> > SYSROOTS/i686-nativesdk-oesdk-linux/usr/local/oecore-i686-i686/sysroots/i686-oesdk-linux/
> > SDKMACHINE=x86-64:
> > SYSROOTS/x86_64-nativesdk-oesdk-linux/usr/local/oecore-x86_64-x86_64/sysroots/x86_64-oesdk-linux
> >
> > while STAGING_INCDIR is different for each machine
> > SDKMACHINE=i686:
> >
> > STAGING_LIBDIR="SYSROOTS/i686-oesdk-linux-nativesdk/usr/local/oecore-i686-i586/sysroots/i686-oesdk-linux/usr/lib/i586-oe-linux"
> >
> > STAGING_LIBDIR="SYSROOTS/i686-oesdk-linux-nativesdk/usr/local/oecore-i686-x86_64/sysroots/i686-oesdk-linux/usr/lib/x86_64-oe-linux"
> >
> > STAGING_LIBDIR="SYSROOTS/i686-oesdk-linux-nativesdk/usr/local/oecore-i686-arm/sysroots/i686-oesdk-linux/usr/lib/armv5te-oe-linux-gnueabi"
> > SDKMACHINE=x86-64:
> >
> > STAGING_LIBDIR="SYSROOTS/x86_64-oesdk-linux-nativesdk/usr/local/oecore-x86_64-i586/sysroots/x86_64-oesdk-linux/usr/lib/i586-oe-linux"
> >
> > STAGING_LIBDIR="SYSROOTS/x86_64-oesdk-linux-nativesdk/usr/local/oecore-x86_64-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/x86_64-oe-linux"
> >
> > STAGING_LIBDIR="SYSROOTS/x86_64-oesdk-linux-nativesdk/usr/local/oecore-x86_64-arm/sysroots/x86_64-oesdk-linux/usr/lib/armv5te-oe-linux-gnueabi"
> >
> > notice that not only SDK_NAME tripple is changing
> > SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TARGET_ARCH}"
> > so we keep it the same across all MACHINES with:
> > NATIVESDK_SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${SDK_ARCH}"
> >
> > but also toplevel SYSROOT is different
> > i686-nativesdk-oesdk-linux
> > i686-oesdk-linux-nativesdk
> > and
> > x86_64-nativesdk-oesdk-linux
> > x86_64-oesdk-linux-nativesdk
> >
> > So nativesdk staging is broken and python-nativesdk should be staged
> > separately for each SDK_ARCH/TARGET_ARCH combination or we need those
> > NATIVESDK_SDK_NAME variables for cross-canadian -> nativesdk deps.
>
> All becomes clear now.
>
> I seem to remember strongly disagreeing with:
>
> SDK_NAME = "oecore-${SDK_ARCH}-${TARGET_ARCH}"
> SDKPATH = "/usr/local/${SDK_NAME}"
>
> that is in bitbake.conf but probably wasn't able to articulate why at
> the time. You'll note that poky.conf does:
>
> SDK_VERSION :=
> "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
> SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${TARGET_ARCH}"
> SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
>
> so the SDKPATH is not dependent on TARGET_ARCH. It doesn't need to
> depend on SDK_ARCH either although that is not the problematic part
> here.
>
> If you think about what is happening, bitbake will reuse the sstate
> files for each nativesdk, they are meant to be equivalent for each
> SDKMACHINE. If you hardcode TARGET_ARCH into the path, they are not.
I'll update my first patch to remove TARGET_ARCH, I'm testing
SDKPATH = "/usr/local/${SDK_NAME_PREFIX}"
now, then we still have to deal with different toplevel SYSROOT (if we
want to use STAGING_LIBDIR etc).
x86_64-nativesdk-oesdk-linux (python-nativesdk)
x86_64-oesdk-linux-nativesdk (gdb-cross-canadian-*)
And that looks even more like another wrong variable to me, but as I've
said in 1st thread (SDK confusion) I normaly don't build SDKs so maybe
there are hidden reasons to stage them in different dirs.
I can use Eric's
${STAGING_DIR}/${HOST_ARCH}-nativesdk${HOST_VENDOR}-${HOST_OS}
to look into right sysroot, but maybe it's again not right direction.
> So I'd say that SDKPATH containing SDK_NAME is clearly bogus and
> TARGET_ARCH needs to be removed in somehow at the very least. Fix that
> and your problems should go away.
Not really but it's getting better :).
> The patches you're sending don't fix the root problem though.
Originaly they were meant mostly to show the difference between
nativesdk and cross-canadian paths.. so I'm not much surprised :).
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
