Re: Break in gcc-linaro tarball naming conventions, was: Re: Bug 809768 integration into gcc 4.6 for Linaro Android 1107 release
(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" 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 wrote: > >> On Wed, 20 Jul 2011 21:44:10 +0100 >> Chao Yang 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-2011.07.tar.bz2 >> instead. >> >> > >> > Thanks and regards >> > On 20 Jul 2011 21:12, "Paul Sokolovsky" >> > wrote: >> > > Hello Ulrich, >> > > >> > > On Wed, 20 Jul 2011 21:07:50 +0200 >> > > Ulrich Weigand wrote: >> > > >> > >> Zach Pfeffer wrote on 07/20/2011 >> > >> 08:56:32 PM: >> > >> > Michael Hope 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: >> > > >> > > 1. 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-2011.07.tar.bz2 >> > > + http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html >> > > 2. 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-2011.07.tar.bz2 >> > > 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äfts
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 wrote: > On Wed, 20 Jul 2011 21:44:10 +0100 > Chao Yang 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-2011.07.tar.bz2 > instead. > > > > > Thanks and regards > > On 20 Jul 2011 21:12, "Paul Sokolovsky" > > wrote: > > > Hello Ulrich, > > > > > > On Wed, 20 Jul 2011 21:07:50 +0200 > > > Ulrich Weigand wrote: > > > > > >> Zach Pfeffer wrote on 07/20/2011 > > >> 08:56:32 PM: > > >> > Michael Hope 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: > > > > > > 1. 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-2011.07.tar.bz2 > > > + http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html > > > 2. 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-2011.07.tar.bz2 > > > 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/#!/linaroorg - > > > http://ww
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 wrote: > On Wed, 20 Jul 2011 21:44:10 +0100 > Chao Yang 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-2011.07.tar.bz2 > instead. > > > > > Thanks and regards > > On 20 Jul 2011 21:12, "Paul Sokolovsky" > > wrote: > > > Hello Ulrich, > > > > > > On Wed, 20 Jul 2011 21:07:50 +0200 > > > Ulrich Weigand wrote: > > > > > >> Zach Pfeffer wrote on 07/20/2011 > > >> 08:56:32 PM: > > >> > Michael Hope 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: > > > > > > 1. 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-2011.07.tar.bz2 > > > + http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01623.html > > > 2. 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-2011.07.tar.bz2 > > > 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/#!/linaroorg - > > > http://ww
