[PATCH 0/3] SRCREVs and fixed building python modules

[PATCH 0/3] SRCREVs and fixed building python modules

[Martin Jansa]

SCM recipes should be usefull without including poky-default-revisions.inc
Building python modules fails without distutils-common-base patch, 
when trying to link against libc from host's /usr/lib

Pull URL: git://git.openembedded.org/openembedded-core-contrib
  Branch: jansa/pull
  Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/pull

Thanks,
    Martin Jansa <Martin.Jansa@gmail.com>
---


Martin Jansa (3):
  distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker
    library search path.
  gconf-dbus: add SRCREV to recipe
  xf86-video-omapfb: add SRCREV to recipe

 meta/classes/distutils-common-base.bbclass         |    2 ++
 meta/recipes-gnome/gnome/gconf-dbus_svn.bb         |    1 +
 .../xorg-driver/xf86-video-omapfb_git.bb           |    1 +
 3 files changed, 4 insertions(+), 0 deletions(-)

-- 
1.7.4.1

[PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.

[Martin Jansa]

* This was done generically in bitbake.conf this should be done on
  demand and distutils based recipes seem to need it. So we define it
  here.
* imported from OE 629ae87eadeec1068c3778e14488b549029adffb

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/classes/distutils-common-base.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta/classes/distutils-common-base.bbclass b/meta/classes/distutils-common-base.bbclass
index f66a5cd..b6caf24 100644
--- a/meta/classes/distutils-common-base.bbclass
+++ b/meta/classes/distutils-common-base.bbclass
@@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""
 
 export STAGING_INCDIR
 export STAGING_LIBDIR
+# libtool 2.4 does not export with LDFLAGS but distutils need it
+LDFLAGS_prepend = "-L${STAGING_LIBDIR} "
 
 PACKAGES = "${PN}-dev ${PN}-dbg ${PN}-doc ${PN}"
 
-- 
1.7.4.1

[PATCH 2/3] gconf-dbus: add SRCREV to recipe

[Martin Jansa]

* taken from meta/conf/distro/include/poky-default-revisions.inc for
  those who want gconf-dbus and are not using poky

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/recipes-gnome/gnome/gconf-dbus_svn.bb |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-gnome/gnome/gconf-dbus_svn.bb b/meta/recipes-gnome/gnome/gconf-dbus_svn.bb
index 9fdd82c..04908c3 100644
--- a/meta/recipes-gnome/gnome/gconf-dbus_svn.bb
+++ b/meta/recipes-gnome/gnome/gconf-dbus_svn.bb
@@ -10,6 +10,7 @@ RPROVIDES_${PN}-dev = "gconf-dev"
 
 PV = "2.16.0+svnr${SRCPV}"
 
+SRCREV = "705"
 SRC_URI = "svn://developer.imendio.com/svn/gconf-dbus;module=trunk;proto=http"
 S = "${WORKDIR}/trunk"
 
-- 
1.7.4.1

[PATCH 3/3] xf86-video-omapfb: add SRCREV to recipe

[Martin Jansa]

* taken from meta/conf/distro/include/poky-default-revisions.inc for
  those who want xf86-video-omapfb and are not using poky

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 .../xorg-driver/xf86-video-omapfb_git.bb           |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb b/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
index 2714786..5281665 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
@@ -13,6 +13,7 @@ PE = "1"
 PR = "r1"
 PV = "0.1.1+git${SRCPV}"
 
+SRCREV = "044617665d6737f4909aab96f91b06261dff05d2"
 SRC_URI = "git://git.pingu.fi/xf86-video-omapfb.git;protocol=http \
             file://omap-revert-set-CRTC-limit.patch \
             file://omap-revert-set-virtual-size.patch \
-- 
1.7.4.1

Re: [PATCH 3/3] xf86-video-omapfb: add SRCREV to recipe

[Koen Kooi]

FWIW, meta-oe has a recipe that has actually been tested on real hardware: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb



Op 31 mrt 2011, om 12:40 heeft Martin Jansa het volgende geschreven:

> * taken from meta/conf/distro/include/poky-default-revisions.inc for
>  those who want xf86-video-omapfb and are not using poky
> 
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> .../xorg-driver/xf86-video-omapfb_git.bb           |    1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb b/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
> index 2714786..5281665 100644
> --- a/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
> +++ b/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
> @@ -13,6 +13,7 @@ PE = "1"
> PR = "r1"
> PV = "0.1.1+git${SRCPV}"
> 
> +SRCREV = "044617665d6737f4909aab96f91b06261dff05d2"
> SRC_URI = "git://git.pingu.fi/xf86-video-omapfb.git;protocol=http \
>             file://omap-revert-set-CRTC-limit.patch \
>             file://omap-revert-set-virtual-size.patch \
> -- 
> 1.7.4.1
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.

[Richard Purdie]

On Thu, 2011-03-31 at 12:40 +0200, Martin Jansa wrote:
> * This was done generically in bitbake.conf this should be done on
>   demand and distutils based recipes seem to need it. So we define it
>   here.
> * imported from OE 629ae87eadeec1068c3778e14488b549029adffb
> 
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
>  meta/classes/distutils-common-base.bbclass |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/distutils-common-base.bbclass b/meta/classes/distutils-common-base.bbclass
> index f66a5cd..b6caf24 100644
> --- a/meta/classes/distutils-common-base.bbclass
> +++ b/meta/classes/distutils-common-base.bbclass
> @@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""
>  
>  export STAGING_INCDIR
>  export STAGING_LIBDIR
> +# libtool 2.4 does not export with LDFLAGS but distutils need it
> +LDFLAGS_prepend = "-L${STAGING_LIBDIR} "

This should not be needed, the linker itself should automatically look
in that path at link time. What problem are you seeing?

Cheers,

Richard

Re: [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.

[Martin Jansa]

On Thu, Mar 31, 2011 at 03:26:39PM +0100, Richard Purdie wrote:
> On Thu, 2011-03-31 at 12:40 +0200, Martin Jansa wrote:
> > * This was done generically in bitbake.conf this should be done on
> >   demand and distutils based recipes seem to need it. So we define it
> >   here.
> > * imported from OE 629ae87eadeec1068c3778e14488b549029adffb
> > 
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> >  meta/classes/distutils-common-base.bbclass |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/meta/classes/distutils-common-base.bbclass b/meta/classes/distutils-common-base.bbclass
> > index f66a5cd..b6caf24 100644
> > --- a/meta/classes/distutils-common-base.bbclass
> > +++ b/meta/classes/distutils-common-base.bbclass
> > @@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""
> >  
> >  export STAGING_INCDIR
> >  export STAGING_LIBDIR
> > +# libtool 2.4 does not export with LDFLAGS but distutils need it
> > +LDFLAGS_prepend = "-L${STAGING_LIBDIR} "
> 
> This should not be needed, the linker itself should automatically look
> in that path at link time. What problem are you seeing?

sorry for delay, my previous reply was refused by mailman at Mon, 04 Apr 2011
with "The message's content type was not explicitly allowed", maybe PGP
sign is not allowed? ;/.


when building any python extra module ie python-numeric I get error like
this

| arm-oe-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb --sysroot=/OE/shr-core/tmp/sysroots/nokia900 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -g -feliminate-unused-debug-types -fPIC -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/OE/shr-core/tmp/sysroots/arm-oe-linux-gnueabi/usr/include/python2.6 -I/OE/shr-core/tmp/sysroots/nokia900/usr/include/python2.6 -c Src/ufuncobject.c -o build/temp.linux-x86_64-2.6/Src/ufuncobject.o
| arm-oe-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb -D__SOFTFP__ --sysroot=/OE/shr-core/tmp/sysroots/nokia900 -shared -Wl,-O1 -Wl,--hash-style=gnu -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -g -feliminate-unused-debug-types build/temp.linux-x86_64-2.6/Src/_numpymodule.o build/temp.linux-x86_64-2.6/Src/arrayobject.o build/temp.linux-x86_64-2.6/Src/ufuncobject.o -L/usr/lib -lpython2.6 -o build/lib.linux-x86_64-2.6/_numpy.so
| /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.3/ldERROR: Function 'do_compile' failed (see /OE/shr-core/tmp/work/armv7a-oe-linux-gnueabi/python-numeric-24.2-ml1/temp/log.do_compile.16227 for further information)
| : warning: library search path "/usr/lib" is unsafe for cross-compilation
| /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.3/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
| /usr/lib/libc.a: could not read symbols: File format not recognized
| collect2: ld returned 1 exit status
| error: command 'arm-oe-linux-gnueabi-gcc' failed with exit status 1
| FATAL: python setup.py build_ext execution failed.
NOTE: package python-numeric-24.2-ml1: task do_compile: Failed
ERROR: Task 4075 (/OE/shr-core/meta-shr/recipes-devtools/python/python-numeric_24.2.bb, do_compile) failed with exit code '1'

in oe we had the same problem after switching to libtool 
with sysroot support IIRC and this was fix for it 
(and it helps with oe-core too)

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.

[Richard Purdie]

On Mon, 2011-04-18 at 07:54 +0200, Martin Jansa wrote:
> On Thu, Mar 31, 2011 at 03:26:39PM +0100, Richard Purdie wrote:
> > On Thu, 2011-03-31 at 12:40 +0200, Martin Jansa wrote:
> > > * This was done generically in bitbake.conf this should be done on
> > >   demand and distutils based recipes seem to need it. So we define it
> > >   here.
> > > * imported from OE 629ae87eadeec1068c3778e14488b549029adffb
> > > 
> > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > ---
> > >  meta/classes/distutils-common-base.bbclass |    2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/meta/classes/distutils-common-base.bbclass b/meta/classes/distutils-common-base.bbclass
> > > index f66a5cd..b6caf24 100644
> > > --- a/meta/classes/distutils-common-base.bbclass
> > > +++ b/meta/classes/distutils-common-base.bbclass
> > > @@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""
> > >  
> > >  export STAGING_INCDIR
> > >  export STAGING_LIBDIR
> > > +# libtool 2.4 does not export with LDFLAGS but distutils need it
> > > +LDFLAGS_prepend = "-L${STAGING_LIBDIR} "
> > 
> > This should not be needed, the linker itself should automatically look
> > in that path at link time. What problem are you seeing?
> 
> sorry for delay, my previous reply was refused by mailman at Mon, 04 Apr 2011
> with "The message's content type was not explicitly allowed", maybe PGP
> sign is not allowed? ;/.
> 
> 
> when building any python extra module ie python-numeric I get error like
> this
> 
> | arm-oe-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb --sysroot=/OE/shr-core/tmp/sysroots/nokia900 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -g -feliminate-unused-debug-types -fPIC -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/OE/shr-core/tmp/sysroots/arm-oe-linux-gnueabi/usr/include/python2.6 -I/OE/shr-core/tmp/sysroots/nokia900/usr/include/python2.6 -c Src/ufuncobject.c -o build/temp.linux-x86_64-2.6/Src/ufuncobject.o
> | arm-oe-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb -D__SOFTFP__ --sysroot=/OE/shr-core/tmp/sysroots/nokia900 -shared -Wl,-O1 -Wl,--hash-style=gnu -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -g -feliminate-unused-debug-types build/temp.linux-x86_64-2.6/Src/_numpymodule.o build/temp.linux-x86_64-2.6/Src/arrayobject.o build/temp.linux-x86_64-2.6/Src/ufuncobject.o -L/usr/lib -lpython2.6 -o build/lib.linux-x86_64-2.6/_numpy.so
> | /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.3/ldERROR: Function 'do_compile' failed (see /OE/shr-core/tmp/work/armv7a-oe-linux-gnueabi/python-numeric-24.2-ml1/temp/log.do_compile.16227 for further information)
> | : warning: library search path "/usr/lib" is unsafe for cross-compilation
> | /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.3/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
> | /usr/lib/libc.a: could not read symbols: File format not recognized
> | collect2: ld returned 1 exit status
> | error: command 'arm-oe-linux-gnueabi-gcc' failed with exit status 1
> | FATAL: python setup.py build_ext execution failed.
> NOTE: package python-numeric-24.2-ml1: task do_compile: Failed
> ERROR: Task 4075 (/OE/shr-core/meta-shr/recipes-devtools/python/python-numeric_24.2.bb, do_compile) failed with exit code '1'
> 
> in oe we had the same problem after switching to libtool 
> with sysroot support IIRC and this was fix for it 
> (and it helps with oe-core too)

This isn't a libtool problem, we've patched that problem out in oe-core
(and I think in OE-dev too now). In this case something is adding
"-L/usr/lib" to the compiler arguments and that is the reason things are
failing. I'd suggesting finding out where that is coming from and fixing
it at source. Yes, it so happens adding other search paths first masks
the problem but it is just masking it, its not a proper fix.

Cheers,

Richard

Re: [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.

[Khem Raj]

On (18/04/11 07:57), Richard Purdie wrote:
> On Mon, 2011-04-18 at 07:54 +0200, Martin Jansa wrote:
> > On Thu, Mar 31, 2011 at 03:26:39PM +0100, Richard Purdie wrote:
> > > On Thu, 2011-03-31 at 12:40 +0200, Martin Jansa wrote:
> > > > * This was done generically in bitbake.conf this should be done on
> > > >   demand and distutils based recipes seem to need it. So we define it
> > > >   here.
> > > > * imported from OE 629ae87eadeec1068c3778e14488b549029adffb
> > > > 
> > > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > > ---
> > > >  meta/classes/distutils-common-base.bbclass |    2 ++
> > > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/meta/classes/distutils-common-base.bbclass b/meta/classes/distutils-common-base.bbclass
> > > > index f66a5cd..b6caf24 100644
> > > > --- a/meta/classes/distutils-common-base.bbclass
> > > > +++ b/meta/classes/distutils-common-base.bbclass
> > > > @@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""
> > > >  
> > > >  export STAGING_INCDIR
> > > >  export STAGING_LIBDIR
> > > > +# libtool 2.4 does not export with LDFLAGS but distutils need it
> > > > +LDFLAGS_prepend = "-L${STAGING_LIBDIR} "
> > > 
> > > This should not be needed, the linker itself should automatically look
> > > in that path at link time. What problem are you seeing?
> > 
> > sorry for delay, my previous reply was refused by mailman at Mon, 04 Apr 2011
> > with "The message's content type was not explicitly allowed", maybe PGP
> > sign is not allowed? ;/.
> > 
> > 
> > when building any python extra module ie python-numeric I get error like
> > this
> > 
> > | arm-oe-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb --sysroot=/OE/shr-core/tmp/sysroots/nokia900 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -g -feliminate-unused-debug-types -fPIC -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/OE/shr-core/tmp/sysroots/arm-oe-linux-gnueabi/usr/include/python2.6 -I/OE/shr-core/tmp/sysroots/nokia900/usr/include/python2.6 -c Src/ufuncobject.c -o build/temp.linux-x86_64-2.6/Src/ufuncobject.o
> > | arm-oe-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb -D__SOFTFP__ --sysroot=/OE/shr-core/tmp/sysroots/nokia900 -shared -Wl,-O1 -Wl,--hash-style=gnu -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -g -feliminate-unused-debug-types build/temp.linux-x86_64-2.6/Src/_numpymodule.o build/temp.linux-x86_64-2.6/Src/arrayobject.o build/temp.linux-x86_64-2.6/Src/ufuncobject.o -L/usr/lib -lpython2.6 -o build/lib.linux-x86_64-2.6/_numpy.so
> > | /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.3/ldERROR: Function 'do_compile' failed (see /OE/shr-core/tmp/work/armv7a-oe-linux-gnueabi/python-numeric-24.2-ml1/temp/log.do_compile.16227 for further information)
> > | : warning: library search path "/usr/lib" is unsafe for cross-compilation
> > | /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.3/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
> > | /usr/lib/libc.a: could not read symbols: File format not recognized
> > | collect2: ld returned 1 exit status
> > | error: command 'arm-oe-linux-gnueabi-gcc' failed with exit status 1
> > | FATAL: python setup.py build_ext execution failed.
> > NOTE: package python-numeric-24.2-ml1: task do_compile: Failed
> > ERROR: Task 4075 (/OE/shr-core/meta-shr/recipes-devtools/python/python-numeric_24.2.bb, do_compile) failed with exit code '1'
> > 
> > in oe we had the same problem after switching to libtool 
> > with sysroot support IIRC and this was fix for it 
> > (and it helps with oe-core too)
> 
> This isn't a libtool problem, we've patched that problem out in oe-core
> (and I think in OE-dev too now). In this case something is adding
> "-L/usr/lib" to the compiler arguments and that is the reason things are
> failing. I'd suggesting finding out where that is coming from and fixing
> it at source. Yes, it so happens adding other search paths first masks
> the problem but it is just masking it, its not a proper fix.

Its added by distutils IIRC when I fixed it in oe.dev with this rev
629ae87eadeec1068c3778e14488b549029adffb this would nullify the addition
since we now have staging libdir before it. 

> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Khem

Re: [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.

[Michael Lippautz]

> This isn't a libtool problem, we've patched that problem out in oe-core
> (and I think in OE-dev too now). In this case something is adding
> "-L/usr/lib" to the compiler arguments and that is the reason things are
> failing. I'd suggesting finding out where that is coming from and fixing
> it at source.
>
Right.

I also noticed this behaviour and started to look after the cause. It
seems that distutils somehow grabs the target (python configured)
Makefile instead of the staging one.

Start of the trouble seems to be [1] where LIBDIR should point into
staging but is reported to be -L/usr/lib from sysconfig.

Maybe someone with more experience on python staging that can follow up.

Regards,
Michael

[1] https://bitbucket.org/carljm/python-distutils/src/48c42eeaee44/command/build_ext.py#cl-286

Re: [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.

[Michael Lippautz]

[usually not answering myself, but:]

The culprit is:
 * distutils.bbclass tries to make python recognize staged libs by
setting STAGING_LIBDIR (correct)
 * distutils recognizes STAGING_LIBDIR and tries to load
python<pyver>/config/Makefile (correct?)
 * since this contains the Makefile that is installed on the target
this brings in -L/usr/lib (obivously not correct)

Without patching the distutils package this leaves us with patching
the Makefile for the target, after packaging it for the target. This
could be done using  SYSROOT_PREPROCESS_FUNCS?

Any comments?

-Michael

2011/4/27 Michael Lippautz <michael.lippautz@gmail.com>:
>> This isn't a libtool problem, we've patched that problem out in oe-core
>> (and I think in OE-dev too now). In this case something is adding
>> "-L/usr/lib" to the compiler arguments and that is the reason things are
>> failing. I'd suggesting finding out where that is coming from and fixing
>> it at source.
>>
> Right.
>
> I also noticed this behaviour and started to look after the cause. It
> seems that distutils somehow grabs the target (python configured)
> Makefile instead of the staging one.
>
> Start of the trouble seems to be [1] where LIBDIR should point into
> staging but is reported to be -L/usr/lib from sysconfig.
>
> Maybe someone with more experience on python staging that can follow up.
>
> Regards,
> Michael
>
> [1] https://bitbucket.org/carljm/python-distutils/src/48c42eeaee44/command/build_ext.py#cl-286
>