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:

quoted

On Thu, Feb 23, 2012 at 10:27:53AM +0000, Richard Purdie wrote:

quoted

On Mon, 2012-02-13 at 16:40 +0100, Martin Jansa wrote:

quoted

* seems like config/config in -L was also wrong

Signed-off-by: Martin Jansa <redacted>
---
 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.Jansa@gmail.com