On 8/15/12 4:39 PM, Richard Purdie wrote:
On Wed, 2012-08-15 at 17:18 +0100, Ross Burton wrote:
GNU Make 3.82 has some regressions regarding parallel processing that causes
some packages to fail, specifically WebKitGTK+. Add make-replacement-native
3.81 so that those packages can depend on a Make which is known to work.
Signed-off-by: Ross Burton <ross.bur...@intel.com>
---
meta/recipes-devtools/make/make-replacement-native_3.81.bb | 6 ++++++
1 file changed, 6 insertions(+)
create mode 100644 meta/recipes-devtools/make/make-replacement-native_3.81.bb
diff --git a/meta/recipes-devtools/make/make-replacement-native_3.81.bb
b/meta/recipes-devtools/make/make-replacement-native_3.81.bb
new file mode 100644
index 0000000..716a8b5
--- /dev/null
+++ b/meta/recipes-devtools/make/make-replacement-native_3.81.bb
@@ -0,0 +1,6 @@
+require make_${PV}.bb
+
+inherit native
+
+BPN = "make"
+EXTRAINSTALL = ""
Unfortunately we have some experience with these replacement recipes and
they need some "special" handling. You need to install make into a
subdirectory off ${bindir} and then add it to PATH in the webkit recipe.
There is precedent for this:
I was looking at the staging code the other day.. I suspect we could eliminate
some of these problems with a few changes.
The order the items are staged is the first. Right now bin and sbin are staged
before libs.. so if we change that, it would resolve some of the problems we've
seen. The second thing is the way the copy itself occurs.. We should really do
this in an atomic fashion.. use install, or copy to an alternative name, and
then 'mv' to the actual name.
Only concern w/ the change to copy could be performance, but I'm really not sure
how severe that is.... might also be possible to do that only in the 'native' cases.
--Mark
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=3f05622bac998f351168eb49a5ca96e7473f51be
So BBCLASSEXTEND the make recipe, add a PROVIDES, then do a
EXTRANATIVEPATH += "make-native" in the webkit recipe.
The reason for this elaborate dance is so we avoid races, nothing should
be executing the make binary when we do anything to it with sstate
(install or remove it). Admittedly this is much more critical when there
is an associated library like bzip but we need to set the right example.
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
