SRCREVs and fixed building python modules
PATCH 1/3 distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.
In reply to 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
--- meta/classes/distutils-common-base.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/distutils-common-base.bbclass +2 -0
@@ -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}"
Signature · 1 line
1.7.4.1
PATCH 2/3 gconf-dbus: add SRCREV to recipe
In reply to Martin Jansa* taken from meta/conf/distro/include/poky-default-revisions.inc for those who want gconf-dbus and are not using poky
--- meta/recipes-gnome/gnome/gconf-dbus_svn.bb | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
meta/recipes-gnome/gnome/gconf-dbus_svn.bb +1 -0
@@ -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"
Signature · 1 line
1.7.4.1
PATCH 3/3 xf86-video-omapfb: add SRCREV to recipe
In reply to Martin Jansa* taken from meta/conf/distro/include/poky-default-revisions.inc for those who want xf86-video-omapfb and are not using poky
--- .../xorg-driver/xf86-video-omapfb_git.bb | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb +1 -0
@@ -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 \
Signature · 1 line
1.7.4.1
cover SRCREVs and fixed building python modules
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 <[email protected]>
---
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(-)
Signature · 1 line
1.7.4.1
Re: [PATCH 3/3] xf86-video-omapfb: add SRCREV to recipe
In reply to Martin JansaFWIW, 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:
Quoted 28 lines
* 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 <[email protected]>---
.../xorg-driver/xf86-video-omapfb_git.bb | 1 +1 files changed, 1 insertions(+), 0 deletions(-)meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb +0
-0@@ -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 \Signature · 7 lines
1.7.4.1 _______________________________________________ Openembedded-core mailing list [email protected] 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.
In reply to Martin JansaQuoted 15 lines · 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 OE629ae87eadeec1068c3778e14488b549029adffbSigned-off-by Martin Jansa <[email protected]>--- meta/classes/distutils-common-base.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)meta/classes/distutils-common-base.bbclass +0
-0
meta/classes/distutils-common-base.bbclass EXTRA_OEMAKE = "" · line 8
Quoted 5 lines
meta/classes/distutils-common-base.bbclass +2
-0@@ -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.
In reply to a message not in the archiveQuoted 17 lines · Richard Purdie
Quoted 16 lines · 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 OE629ae87eadeec1068c3778e14488b549029adffbSigned-off-by Martin Jansa <[email protected]>--- meta/classes/distutils-common-base.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)meta/classes/distutils-common-base.bbclass +0
-0@@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""
Quoted 7 lines
meta/classes/distutils-common-base.bbclass EXTRA_OEMAKE = "" · line 8
Quoted 4 lines
meta/classes/distutils-common-base.bbclass +2
-0export 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,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.
Quoted 43 lines · Martin Jansa
Quoted 17 lines · Richard Purdie
Quoted 16 lines · 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 OE629ae87eadeec1068c3778e14488b549029adffbSigned-off-by Martin Jansa <[email protected]>--- meta/classes/distutils-common-base.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)meta/classes/distutils-common-base.bbclass +0
-0@@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""Quoted 7 lines
meta/classes/distutils-common-base.bbclass EXTRA_OEMAKE = "" · line 8
Quoted 4 lines
meta/classes/distutils-common-base.bbclass +2
-0export 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.
Quoted 6 lines
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.
Quoted 51 lines · Richard Purdie
Quoted 43 lines · Martin Jansa
Quoted 17 lines · Richard Purdie
Quoted 16 lines · 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 OE629ae87eadeec1068c3778e14488b549029adffbSigned-off-by Martin Jansa <[email protected]>--- meta/classes/distutils-common-base.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)meta/classes/distutils-common-base.bbclass +0
-0@@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""Quoted 7 lines
meta/classes/distutils-common-base.bbclass EXTRA_OEMAKE = "" · line 8
Quoted 4 lines
meta/classes/distutils-common-base.bbclass +2
-0export 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.Quoted 6 lines
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)
Quoted 6 lines
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.
Quoted 10 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
-Khem
Re: [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.
In reply to Richard PurdieQuoted 6 lines
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.
[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 <[email protected]>:
Quoted 22 lines
Quoted 6 lines
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)
Makefileinstead 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