1948 2012-02-01 12:31:43 +0000 distutils builds are using "cached" environment from sstate-cache 2012-02-10 08:27:25 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto 1.1.1 x86 Multiple RESOLVED FIXED Medium normal 1.2 M3 1 msm-oss richard.purdie josh msm-oss nitin.a.kamble poky.bs.watcher poky.watcher sgw --- --- --- oldest_to_newest 18447 0 msm-oss 2012-02-01 12:31:43 +0000 Recipes that use distuils are pulling in some cached build steps/information from sstate-cache. Basically, let's say I build for BOARDA, then I delete that and reuse the sstate-cache for a BOARDB. The BOARDB link step will reuse the --sysroot from BOARDA instead of using the sysroot from BOARDB. A problem recipe is python-pycairo. I was able to add the following patch to "hack" around the issue. I suspect a better fix is to add these exports to meta/classes/distutils.bbclass - or somehow delete wherever this bad information is cached and avoid packaging that information in sstate-cache in the first place. diff --git a/meta/recipes-devtools/python/python-pycairo_1.8.10.bb b/meta/recipes-devtools/python/python-pycairo_1.8.10.bb index b76724e..ee57978 100644 --- a/meta/recipes-devtools/python/python-pycairo_1.8.10.bb +++ b/meta/recipes-devtools/python/python-pycairo_1.8.10.bb @@ -6,7 +6,7 @@ LICENSE = "LGPLv2.1 & MPL-1" LIC_FILES_CHKSUM = "file://COPYING;md5=f2e071ab72978431b294a0d696327421" # cairo >= 1.8.8 DEPENDS = "cairo" -PR = "r1" +PR = "r2" SRC_URI = "http://cairographics.org/releases/py2cairo-${PV}.tar.gz" @@ -20,6 +20,10 @@ do_compile_prepend() { #fix the installation path of __init__.py #It was going in the sysroot instead of target install location sed -i -e "s#dsy.get_python_lib()#'${D}${PYTHON_SITEPACKAGES_DIR}'#" ${S}/setup.py + +# Append "correct" sysroot to linker step otherwise it's possible to use sysroot from +# whatever sstate-cache was built against which would be wrong + export LDFLAGS="${LDFLAGS} ${TOOLCHAIN_OPTIONS}" } 18455 1 richard.purdie 2012-02-01 16:17:34 +0000 If no flags are passed to the linker it will use its builtin sysroot option which as you point out, can be incorrect in sstate builds. We cannot change the builtin values easily, we should however always ensure our linker command is being used. The question is why is $LD not being used? or $CCLD? 18456 2 msm-oss 2012-02-01 16:29:33 +0000 (In reply to comment #1) > If no flags are passed to the linker it will use its builtin sysroot option > which as you point out, can be incorrect in sstate builds. We cannot change the > builtin values easily, we should however always ensure our linker command is > being used. The question is why is $LD not being used? or $CCLD? I tried: export LD=${LD} first with no luck. -M 18528 3 msm-oss 2012-02-07 09:00:36 +0000 adding Nitin to see if he has any thoughts 18529 4 nitin.a.kamble 2012-02-07 09:36:27 +0000 I am seeing this in the run.do_compile export LD="x86_64-poky-linux-ld --sysroot=/builddisk/build/build0/tmp/sysroots/qemux86-64" export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" 18530 5 nitin.a.kamble 2012-02-07 09:41:53 +0000 and config.status inside python-pycairo has LD='/usr/bin/ld -m elf_x86_64' 18531 6 nitin.a.kamble 2012-02-07 10:20:45 +0000 Matthew, Does this work? export LINK_CC=${LD} PS: ignore the config.status comment, this file is a stale file in the source, and not part of the build process. 18532 7 msm-oss 2012-02-07 13:15:58 +0000 (In reply to comment #6) > Matthew, > Does this work? > > export LINK_CC=${LD} > > > PS: ignore the config.status comment, this file is a stale file in the source, > and not part of the build process. diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass index 79b962a..cdbcdd0 100644 --- a/meta/classes/distutils.bbclass +++ b/meta/classes/distutils.bbclass @@ -72,3 +72,5 @@ distutils_do_install() { } EXPORT_FUNCTIONS do_compile do_install + +export LINK_CC=${LD} Still get the error below. LINK_CC or LD from the environment don't override the linker flags distutils uses. | powerpc-fsl-linux-gcc -m32 -mhard-float -mcpu=e500mc --sysroot=/opt/yocto/cache-build/p4080ds/build_p4080ds_release/tmp/sysroots/p4080ds -shared -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -O2 -pipe -g -feliminate-unused-debug-types build/temp.linux-x86_64-2.6/src/cairomodule.o build/temp.linux-x86_64-2.6/src/context.o build/temp.linux-x86_64-2.6/src/font.o build/temp.linux-x86_64-2.6/src/matrix.o build/temp.linux-x86_64-2.6/src/path.o build/temp.linux-x86_64-2.6/src/pattern.o build/temp.linux-x86_64-2.6/src/surface.o -L/opt/yocto/cache-build/p4080ds/build_p4080ds_release/tmp/sysroots/p4080ds/usr/lib -lcairo -lpython2.6 -o build/lib.linux-x86_64-2.6/cairo/_cairo.so | /local/home/mattsm/git/poky/build_p3041ds_release/tmp/sysroots/x86_64-linux/usr/bin/ppce500mc-fsl-linux/../../libexec/ppce500mc-fsl-linux/gcc/powerpc-fsl-linux/4.6.3/ld: cannot find crti.o: No such file or directory | /local/home/mattsm/git/poky/build_p3041ds_release/tmp/sysroots/x86_64-linux/usr/bin/ppce500mc-fsl-linux/../../libexec/ppce500mc-fsl-linux/gcc/powerpc-fsl-linux/4.6.3/ld: cannot find crtbeginS.o: No such file or directory 18533 8 msm-oss 2012-02-07 13:17:07 +0000 The above example uses state-cache from the p4080ds machine, on a p3041ds machine. You can see the incorrect sysroot argument in the pasted text. 18534 9 nitin.a.kamble 2012-02-07 13:26:11 +0000 Matthew, Is the gcc (path & filename) and gcc parameters especially sysroot in the log correct ? Looks like issue with $CC rather than $LD 18535 10 nitin.a.kamble 2012-02-07 13:32:17 +0000 Matthew, Can you give definite steps for reproducing the issue? 18536 11 josh 2012-02-07 13:41:20 +0000 (In reply to comment #10) > Matthew, > Can you give definite steps for reproducing the issue? Matthew provided these to me privately: To reproduce you need to build something that uses distutil on one machine and reuse the state cache on another machine or just change the paths on the second build from sstate-cache. $ git clone poky.git poky1 $ cd poky1 $ source oe-env-build $ bitbake python-pycairo $ cd .. $ git clone poky.git poky2 $ cd poky2 $ source oe-env-build $ cp -r ../../poky1/build/sstate-cache/ . $ rm -rf ../../poky1 $ bitbake python-pycairo 18537 12 nitin.a.kamble 2012-02-07 15:46:56 +0000 I could not reproduce the issue following Joshua's steps. Matthew can you provide steps to reproduce the issue? 18539 13 msm-oss 2012-02-07 16:45:52 +0000 (In reply to comment #9) > Matthew, Is the gcc (path & filename) and gcc parameters especially sysroot in > the log correct ? > > Looks like issue with $CC rather than $LD Only for the linking step... the compile step uses the correct parameters. That's what's fishy here, just the compiler issue. 18548 14 msm-oss 2012-02-08 11:47:45 +0000 This is what we are looking for to override for the distutils linker: diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass index 79b962a..18ae805 100644 --- a/meta/classes/distutils.bbclass +++ b/meta/classes/distutils.bbclass @@ -72,3 +72,5 @@ distutils_do_install() { } EXPORT_FUNCTIONS do_compile do_install + +export LDSHARED="${CCLD} -shared" I will submit a patch if there are no further comments on using this to solve the linking sstate-cache problem 18549 15 nitin.a.kamble 2012-02-08 12:26:58 +0000 Matthew, Can you explain how the LDSHARED var is getting used in the code? I did not find anything obvious in the waf code. Nitin 18550 16 msm-oss 2012-02-08 12:29:20 +0000 (In reply to comment #15) > Matthew, > Can you explain how the LDSHARED var is getting used in the code? > I did not find anything obvious in the waf code. > > Nitin See: tmp/work/x86_64-linux/python-native-2.6.6-r2.4/Python-2.6.6/Lib/distutils/sysconfig.py It's importing LDSHARED from the environment to use as the linker. -M 18551 17 msm-oss 2012-02-08 13:07:06 +0000 Patch sent to ML for review 18582 18 josh 2012-02-09 23:26:05 +0000 I can reproduce this issue with the steps in comment 11. With the submitted patch applied to the edison branch I can no longer reproduce the issue. 18587 19 richard.purdie 2012-02-10 08:27:25 +0000 Fixed in master with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=433f2ead93438e0d4d59b24ed3d6097dd658972f, thanks Matthew!