| Summary: | distutils builds are using "cached" environment from sstate-cache | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Meta-yocto | Reporter: | Matthew McClintock <msm-oss> |
| Component: | meta-yocto | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | josh, msm-oss, nitin.a.kamble, poky.bs.watcher, poky.watcher, sgw |
| Version: | 1.1.1 | ||
| Target Milestone: | 1.2 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Matthew McClintock
2012-02-01 12:31:43 UTC
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? (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 adding Nitin to see if he has any thoughts 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" and config.status inside python-pycairo has LD='/usr/bin/ld -m elf_x86_64' 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.
(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 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. Matthew, Is the gcc (path & filename) and gcc parameters especially sysroot in the log correct ? Looks like issue with $CC rather than $LD Matthew, Can you give definite steps for reproducing the issue? (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 I could not reproduce the issue following Joshua's steps. Matthew can you provide steps to reproduce the issue? (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. 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
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 (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 Patch sent to ML for review 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. Fixed in master with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=433f2ead93438e0d4d59b24ed3d6097dd658972f, thanks Matthew! |