sanity.bbclass: Check for the known broken version of make
PATCH v2 1/3 sanity.bbclass: Check for the known broken version of make
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue.
--- meta/classes/sanity.bbclass | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
meta/classes/sanity.bbclass +37 -0
@@ -306,6 +306,42 @@ def check_gcc_march(sanity_data): return result +# Unpatched versions of make 3.82 are known to be broken. See GNU Savannah Bug 30612. +# Use a modified reproducer from http://savannah.gnu.org/bugs/?30612 to validate. +def check_make_version(sanity_data): + from distutils.version import LooseVersion + status, result = oe.utils.getstatusoutput("make --version") + if status != 0: + return "Unable to execute make --version, exit code %s\n" % status + version = result.split()[2] + if LooseVersion(version) == LooseVersion("3.82"): + # Construct a test file + f = open("makefile_test", "w") + f.write("makefile_test.a: makefile_test_a.c makefile_test_b.c makefile_test.a( makefile_test_a.c makefile_test_b.c)\n") + f.write("\n") + f.write("makefile_test_a.c:\n") + f.write(" touch $@\n") + f.write("\n") + f.write("makefile_test_b.c:\n") + f.write(" touch $@\n") + f.close() + + # Check if make 3.82 has been patched + status,result = oe.utils.getstatusoutput("make -f makefile_test") + + os.remove("makefile_test") + if os.path.exists("makefile_test_a.c"): + os.remove("makefile_test_a.c") + if os.path.exists("makefile_test_b.c"): + os.remove("makefile_test_b.c") + if os.path.exists("makefile_test.a"): + os.remove("makefile_test.a") + + if status != 0: + return "Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n" + return None + + # Tar version 1.24 and onwards handle overwriting symlinks correctly # but earlier versions do not; this needs to work properly for sstate def check_tar_version(sanity_data):
@@ -436,6 +472,7 @@ def check_sanity_version_change(status, d): except ImportError: status.addresult('Your python is not a full install. Please install the module xml.parsers.expat (python-xml on openSUSE and SUSE Linux).\n') + status.addresult(check_make_version(d)) status.addresult(check_tar_version(d)) status.addresult(check_git_version(d))
Signature · 1 line
1.8.3.1
Quoted 8 lines · Mark Hatle
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue.
Signed-off-by Mark Hatle <[email protected]>
Verified that this detects the 3.82 in Debian's experimental repository that is well and truly broken.
Ross
Quoted 8 lines · Ross
Quoted 7 lines · Mark Hatle
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue.
Quoted 7 lines
Quoted 1 line
Signed-off-by Mark Hatle <[email protected]>Verified that this detects the 3.82 in Debian's experimental repository that is well and truly broken.
Signed-off-by Ross Burton <[email protected]>
This picks out the current version of make in Arch Linux as broken despite it having a patch for bug #30612. I'm not sure if this is intended, could be that the applied patch isn't a complete fix. I don't have time to dig into this, just thought it'd be useful to you to know.
If you know what fix you're looking for, the applied patches and build script can be seen at
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/make
Thanks,
--
Paul Barker
Quoted 14 lines · Paul Barker
Quoted 13 lines · Ross
Quoted 8 lines · Mark Hatle
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue.
Signed-off-by Mark Hatle <[email protected]>Verified that this detects the 3.82 in Debian's experimental repository that is well and truly broken.
Quoted 8 lines
Quoted 2 lines
Signed-off-by Ross Burton <[email protected]>This picks out the current version of make in Arch Linux as broken despite it having a patch for bug #30612. I'm not sure if this is intended, could be that the applied patch isn't a complete fix. I don't have time to dig into this, just thought it'd be useful to you to know.
This is exactly why the check is being done. From what I found there are a number of make versions on various distros that only have partial fixes for bug 30612.
For the RedHat/Fedora bug I filed, see:
https://bugzilla.redhat.com/show_bug.cgi?id=975597
The test case, and a patch to the missing commit are listed.
http://git.savannah.gnu.org/cgit/make.git/commit/?id=b06b8c64a29a5ba3a8daecd829fa2f98d42cb285
Quoted 3 lines
If you know what fix you're looking for, the applied patches and build script can be seen at
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/make
Looking at that list, it appears the commit referenced above is indeed the one missing.
--Mark
Quoted 8 lines
Thanks,
--
Paul Barker
Quoted 11 lines · Mark Hatle
Quoted 6 lines · Paul Barker
This picks out the current version of make in Arch Linux as broken despite it having a patch for bug #30612. I'm not sure if this is intended, could be that the applied patch isn't a complete fix. I don't have time to dig into this, just thought it'd be useful to you to know.
This is exactly why the check is being done. From what I found there are
a number of make versions on various distros that only have partial fixes for bug 30612.
Quoted 8 lines
For the RedHat/Fedora bug I filed, see:
https://bugzilla.redhat.com/show_bug.cgi?id=975597The test case, and a patch to the missing commit are listed.
http://git.savannah.gnu.org/cgit/make.git/commit/?id=b06b8c64a29a5ba3a8daecd829fa2f98d42cb285
Quoted 5 lines
Quoted 5 lines
If you know what fix you're looking for, the applied patches and build script can be seen at
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/make
Quoted 3 lines
Looking at that list, it appears the commit referenced above is indeed
the one missing.
Quoted 1 line
I'll email the relevant people within arch linux later. Most of my important builds are done on Ubuntu server 12.04 anyway.
Paul Barker
Quoted 10 lines · Paul Barker
Quoted 8 lines · Mark Hatle
Quoted 4 lines · Paul Barker
If you know what fix you're looking for, the applied patches and build script can be seen at
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/make
Quoted 7 lines
Quoted 3 lines
Looking at that list, it appears the commit referenced above is indeed the one missing.
I'll email the relevant people within arch linux later. Most of my important builds are done on Ubuntu server 12.04 anyway.
Bug filed: https://bugs.archlinux.org/task/35968
--
Paul Barker
meta/classes/sanity.bbclass def check_gcc_march(sanity_data): · line 341
Quoted 12 lines · Mark Hatle
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue.
Signed-off-by Mark Hatle <[email protected]>---
meta/classes/sanity.bbclass +3
-0+ + if status != 0: + return "Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n"
Instead of returning an error and asking the user to manually update their own 'make', wouldn't it be better if bitbake simply built its own known-to-be-working -native version instead? In this way a good, working version of 'make' could be installed in a potential SDK's sysroot as well?
Quoted 15 lines · Trevor Woerner
meta/classes/sanity.bbclass def check_gcc_march(sanity_data): · line 341
Quoted 12 lines · Mark Hatle
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue.
Signed-off-by Mark Hatle <[email protected]>---
meta/classes/sanity.bbclass +3
-0+ + if status != 0: + return "Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n"
Quoted 5 lines
Instead of returning an error and asking the user to manually update their own 'make', wouldn't it be better if bitbake simply built its own known-to-be-working -native version instead? In this way a good, working version of 'make' could be installed in a potential SDK's sysroot as well?
Is the broken version good enough to build a working version?
Philip
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 16 lines · Philip Balister
Quoted 15 lines · Trevor Woerner
Quoted 12 lines · Mark Hatle
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue.
Signed-off-by Mark Hatle <[email protected]>---
meta/classes/sanity.bbclass +3
-0+ + if status != 0: + return "Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n"
Quoted 7 lines
Quoted 5 lines
Instead of returning an error and asking the user to manually update their own 'make', wouldn't it be better if bitbake simply built its own known-to-be-working -native version instead? In this way a good, working version of 'make' could be installed in a potential SDK's sysroot as well?
Is the broken version good enough to build a working version?
In my case that's what I did (i.e. I used make-3.82 to build and install early in my $PATH make-3.81). I was then able to bitbake again which went to completion successfully.
Quoted 16 lines · Philip Balister
Quoted 15 lines · Trevor Woerner
Quoted 12 lines · Mark Hatle
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking for just the version string is not enough. We also need to check if the patch for the issue has been applied. We use a modified version of the reproduced to check for the issue.
Signed-off-by Mark Hatle <[email protected]>---
meta/classes/sanity.bbclass +3
-0+ + if status != 0: + return "Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n"
Quoted 7 lines
Quoted 5 lines
Instead of returning an error and asking the user to manually update their own 'make', wouldn't it be better if bitbake simply built its own known-to-be-working -native version instead? In this way a good, working version of 'make' could be installed in a potential SDK's sysroot as well?
Is the broken version good enough to build a working version?
(Catching up on email after my vacation...)
That is the primary issue, can we even trust the host system to work well enough to build a working version.
Second, there was recently a change to oe-core that got rid of all of the "bootstrap" builds, in favor of the 'buildtools'. For anyone with an old or broken system, they will need to download (or build) the buildtools.. install it and have it in their path prior to running oe-core.
This will provide the basic set of python, tar, git, and make that is needed for the build system.
On a "working" host, you can use bitbake buildtools-tarball to generate it.
--Mark
Quoted 9 lines
Philip
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 3 lines · Mark Hatle
For anyone with an old or
broken system, they will need to download (or build) the buildtools.. install it and have it in their path prior to running oe-core.
Does a download location already exist with downloads available for people who receive this error when building? If so, could it be made part of the error message? Or maybe instead of asking people to use a working version of "make" the error message could instruct them to use one of these buildtools-tarball SDKs (and provide instructions for doing so)?
Quoted 11 lines · On Tuesday 09 July 2013 16:14:55 Trevor Woerner wrote:
Quoted 3 lines · Mark Hatle
For anyone with an old or broken system, they will need to download (or build) the buildtools..
install it and have it in their path prior to running oe-core.Does a download location already exist with downloads available for people who receive this error when building? If so, could it be made part of the error message? Or maybe instead of asking people to use a working version of "make" the error message could instruct them to use one of these buildtools-tarball SDKs (and provide instructions for doing so)?
According to Beth, the current (nightly build) can be found here:
http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/buildtools/
Location for the upcoming 1.5 release when that is available:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/buildtools/
The tricky part is we don't have a solid location yet, only one being built from master. Perhaps we could link to an intermediary page with explanatory text that can link to the appropriate location.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 17 lines · Paul Eggleton
Quoted 11 lines · On Tuesday 09 July 2013 16:14:55 Trevor Woerner wrote:
Quoted 3 lines · Mark Hatle
For anyone with an old or broken system, they will need to download (or build) the buildtools..
install it and have it in their path prior to running oe-core.Does a download location already exist with downloads available for people who receive this error when building? If so, could it be made part of the error message? Or maybe instead of asking people to use a working version of "make" the error message could instruct them to use one of these buildtools-tarball SDKs (and provide instructions for doing so)?
According to Beth, the current (nightly build) can be found here:
http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/buildtools/
Quoted 7 lines
Location for the upcoming 1.5 release when that is available:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/buildtools/
The tricky part is we don't have a solid location yet, only one being built from master. Perhaps we could link to an intermediary page with explanatory text that can link to the appropriate location.
That would be quite helpful, and maybe even help people to help themselves should they come across this problem when trying to build.