Break in gcc-linaro tarball naming conventions, was: Re: Bug 809768 integration into gcc 4.6 for Linaro Android 1107 release
Hello,
Well, before proceeding further, there seems that tarball naming convention has changed. For example, now it's gcc-linaro-4.6-2011.07.tar.bz2 whereas before it was gcc-linaro-4.6-2011.06-0.tar.bz2 . What's worse is that inside it's still gcc-linaro-4.6-2011.07-0 top-level directory. The build script uses tarball basename to find out uncompressed dir name, so builds fail now. This can be worked around on build script level, but is example of random inconsistency, and if let such will proliferate, there will be more and more workarounds everywhere, so would be nice if toolchain WG fixed tarball name on their side.
Thanks, Paul
On Thu, 21 Jul 2011 10:18:21 +0300 Paul Sokolovsky Paul.Sokolovsky@linaro.org wrote:
On Wed, 20 Jul 2011 21:44:10 +0100 Chao Yang chao.yang@linaro.org wrote:
Hi Paul,
Just a reminder that the bug was found in gcc 4.6, to which, I think, the patch should apply, not 4.5 only.
Oops, sure, I just copied the wrong link, it should be http://launchpad.net/gcc-linaro/4.6/4.6-2011.07/+download/gcc-linaro-4.6-201... instead.
Thanks and regards On 20 Jul 2011 21:12, "Paul Sokolovsky" paul.sokolovsky@linaro.org wrote:
Hello Ulrich,
On Wed, 20 Jul 2011 21:07:50 +0200 Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
Zach Pfeffer zach.pfeffer@linaro.org wrote on 07/20/2011 08:56:32 PM:
Michael Hope michael.hope@linaro.org wrote:
Hey, we're getting ahead of ourselves here. The patch clears the problem but it hasn't landed upstream and may not be correct. We also haven't laid the ground work for triaging the problem including:
- Describing the compiler involved (mainly how it's built)
- Reducing to a test case (normally preprocessed source)
- Reproducing and reducing the fault
Any fix can introduce other bugs, so it's generally best to work around a last minute issue and then test it properly for the next release. We have a range of options:
- Work around it in the packaging (such as changing the
optimisation level, turning of debug, etc)
- Work around it in the source
- Carry a local patch to GCC
- Use an earlier release (say 2011.05)
We should talk about this in Cambourne especially in untangling what the Android compiler is, how it's built, and adding it as a test case for our releases.
Michael,
Thanks for the feedback. Lets chat at Cambourne. For right now, can we reference Ken's tree to build a WIP Android to facilitate debugging? Could Ken continue to work with Chao to create a testcase that shows the bug? I have our session on Wednesday at 11:00 AM now where we can sort out some more structural issues.
[Pulling in Richard on CC as well.]
Note that by now Richard has done a proper fix of the underlying compiler problem, which has now landed upstream: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html
So my recommendation would be to use this month's Linaro GCC release with Richard's patch on top as the basis for the Android compiler. (By next month, I'd assume Linaro GCC will contain Richard's patch to start with.)
That sounds like good plan. So, what process the toolchain team would suggest for this? I can imagine few choices:
- Toolchain team prepares a tarball for Android team, which is
http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-201...
- Toolchain team creates a bzr branch withich is 2011.07 release
(with any possible bugfix releases) + that patch applied. 3. I just add support for applying patches to android-build and build
http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-201...
with the patch applied.
My own preference probably would be even p.3, as it doesn't create extra entities, but as we want more people try and adopt Linaro tools, p.1 would be still preferable I guess.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
(On holiday so short)
The tarball name has changed to match the new Linaro conventions. I forgot to put that in the announcement. The inner directory name should change as well but was missed, sorry. On Jul 21, 2011 6:59 PM, "Paul Sokolovsky" paul.sokolovsky@gmail.com wrote:
Hello,
Well, before proceeding further, there seems that tarball naming convention has changed. For example, now it's gcc-linaro-4.6-2011.07.tar.bz2 whereas before it was gcc-linaro-4.6-2011.06-0.tar.bz2 . What's worse is that inside it's still gcc-linaro-4.6-2011.07-0 top-level directory. The build script uses tarball basename to find out uncompressed dir name, so builds fail now. This can be worked around on build script level, but is example of random inconsistency, and if let such will proliferate, there will be more and more workarounds everywhere, so would be nice if toolchain WG fixed tarball name on their side.
Thanks, Paul
On Thu, 21 Jul 2011 10:18:21 +0300 Paul Sokolovsky Paul.Sokolovsky@linaro.org wrote:
On Wed, 20 Jul 2011 21:44:10 +0100 Chao Yang chao.yang@linaro.org wrote:
Hi Paul,
Just a reminder that the bug was found in gcc 4.6, to which, I think, the patch should apply, not 4.5 only.
Oops, sure, I just copied the wrong link, it should be
http://launchpad.net/gcc-linaro/4.6/4.6-2011.07/+download/gcc-linaro-4.6-201...
instead.
Thanks and regards On 20 Jul 2011 21:12, "Paul Sokolovsky" paul.sokolovsky@linaro.org wrote:
Hello Ulrich,
On Wed, 20 Jul 2011 21:07:50 +0200 Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
Zach Pfeffer zach.pfeffer@linaro.org wrote on 07/20/2011 08:56:32 PM:
Michael Hope michael.hope@linaro.org wrote: > Hey, we're getting ahead of ourselves here. The patch clears > the problem but it hasn't landed upstream and may not be > correct. We also haven't laid the ground work for triaging > the problem including: > * Describing the compiler involved (mainly how it's built) > * Reducing to a test case (normally preprocessed source) > * Reproducing and reducing the fault > > Any fix can introduce other bugs, so it's generally best to > work around a last minute issue and then test it properly for > the next release. We have a range of options: > * Work around it in the packaging (such as changing the > optimisation level, turning of debug, etc) > * Work around it in the source > * Carry a local patch to GCC > * Use an earlier release (say 2011.05) > > We should talk about this in Cambourne especially in > untangling what the Android compiler is, how it's built, and > adding it as a test case for our releases.
Michael,
Thanks for the feedback. Lets chat at Cambourne. For right now, can we reference Ken's tree to build a WIP Android to facilitate debugging? Could Ken continue to work with Chao to create a testcase that shows the bug? I have our session on Wednesday at 11:00 AM now where we can sort out some more structural issues.
[Pulling in Richard on CC as well.]
Note that by now Richard has done a proper fix of the underlying compiler problem, which has now landed upstream: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html
So my recommendation would be to use this month's Linaro GCC release with Richard's patch on top as the basis for the Android compiler. (By next month, I'd assume Linaro GCC will contain Richard's patch to start with.)
That sounds like good plan. So, what process the toolchain team would suggest for this? I can imagine few choices:
- Toolchain team prepares a tarball for Android team, which is
http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-201...
- Toolchain team creates a bzr branch withich is 2011.07 release
(with any possible bugfix releases) + that patch applied. 3. I just add support for applying patches to android-build and build
http://launchpad.net/gcc-linaro/4.5/4.5-2011.07/+download/gcc-linaro-4.5-201...
with the patch applied.
My own preference probably would be even p.3, as it doesn't create extra entities, but as we want more people try and adopt Linaro tools, p.1 would be still preferable I guess.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
-- Best Regards, Paul
-
Michael Hope -
Paul Sokolovsky