| Message ID | 1453936359-10115-1-git-send-email-cardoe@cardoe.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 28.01.16 at 00:12, <cardoe@cardoe.com> wrote: > To help people avoid having to figure out what versions of make and > binutils need to be supported document them explicitly. The version of > binutils that had to be supported was mentioned in > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.html > as 2.17 recently. It was decided that the versions should instead be > GNU binutils 2.16.1 and GNU Make 3.80 in > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02134.html "decided" is a bit strong. I suggested these values. And while I'm pretty certain that even plain make 3.80 will work, I'm in no way sure plain 2.16.1 will (what I'm building with once in a while is some 2.16.9x, and I can't say how many backports it has). So the question really is - did you test that things build with these? Also I'm not sure 2.16.1 is going to be sufficient for ARM (it's most definitely too old for ARM64). Jan
On Thu, 2016-01-28 at 05:49 -0700, Jan Beulich wrote: > > > > On 28.01.16 at 00:12, <cardoe@cardoe.com> wrote: > > To help people avoid having to figure out what versions of make and > > binutils need to be supported document them explicitly. The version of > > binutils that had to be supported was mentioned in > > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.ht > > ml > > as 2.17 recently. It was decided that the versions should instead be > > GNU binutils 2.16.1 and GNU Make 3.80 in > > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02134.ht > > ml > > "decided" is a bit strong. I suggested these values. And while I'm > pretty certain that even plain make 3.80 will work, I'm in no way > sure plain 2.16.1 will (what I'm building with once in a while is some > 2.16.9x, and I can't say how many backports it has). So the > question really is - did you test that things build with these? Why would he have done, you suggested 2.16.1 with no hint that you thought it might not be a reasonable version to use. TBH having rejected Doug's original proposal I would have said it was up to you to specify the actual precise versions you think should be used, rather than making Doug guess and leading him down blind allies by making apparently authoritative suggestions which you secretly aren't actually sure about yourself. Anyway we could go round and round like this forever. What's wrong with starting with this as a baseline and bumping it if it turns out to be a problem in practice? > Also I'm not sure 2.16.1 is going to be sufficient for ARM (it's > most definitely too old for ARM64). I suppose there is an implicit max(version, first version supporting arch). I don't think we can really go into the level of detail needed for per arch toolchain requirements. I certainly don't know which version of either gcc or binutils is needed to build either ARM variant. Ian.
>>> On 28.01.16 at 14:02, <ian.campbell@citrix.com> wrote: > On Thu, 2016-01-28 at 05:49 -0700, Jan Beulich wrote: >> > > > On 28.01.16 at 00:12, <cardoe@cardoe.com> wrote: >> > To help people avoid having to figure out what versions of make and >> > binutils need to be supported document them explicitly. The version of >> > binutils that had to be supported was mentioned in >> > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.ht >> > ml >> > as 2.17 recently. It was decided that the versions should instead be >> > GNU binutils 2.16.1 and GNU Make 3.80 in >> > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02134.ht >> > ml >> >> "decided" is a bit strong. I suggested these values. And while I'm >> pretty certain that even plain make 3.80 will work, I'm in no way >> sure plain 2.16.1 will (what I'm building with once in a while is some >> 2.16.9x, and I can't say how many backports it has). So the >> question really is - did you test that things build with these? > > Why would he have done, you suggested 2.16.1 with no hint that you thought > it might not be a reasonable version to use. > > TBH having rejected Doug's original proposal I would have said it was up to > you to specify the actual precise versions you think should be used, rather > than making Doug guess and leading him down blind allies by making > apparently authoritative suggestions which you secretly aren't actually > sure about yourself. To be honest it didn't even occur to me that someone might propose such a patch without verifying things actually build (unless using more cautious wording). Also note that in the first reply to the v1 patch I did refer to 2.16.9x (which imo has made clear that that's the lowest one I ever tested with recently), i.e. I don't think I've actively mislead him. > Anyway we could go round and round like this forever. What's wrong with > starting with this as a baseline and bumping it if it turns out to be a > problem in practice? Well, we certainly could (which would be in line with my second reply to v1), just that I'm not sure how much value such a doc addition then has. At the very least it should then say "no lower than 2.16.1, something slightly newer may be needed" or some such. >> Also I'm not sure 2.16.1 is going to be sufficient for ARM (it's >> most definitely too old for ARM64). > > I suppose there is an implicit max(version, first version supporting arch). > I don't think we can really go into the level of detail needed for per arch > toolchain requirements. I'm afraid quite frequently "first version supporting arch" isn't good enough. If we know otherwise for ARM64, that's certainly fine. > I certainly don't know which version of either gcc or binutils is needed to > build either ARM variant. Well, again - what's that documentation addition then good for? Jan
On 1/28/16 7:47 AM, Jan Beulich wrote: >>>> On 28.01.16 at 14:02, <ian.campbell@citrix.com> wrote: >> On Thu, 2016-01-28 at 05:49 -0700, Jan Beulich wrote: >>>>>> On 28.01.16 at 00:12, <cardoe@cardoe.com> wrote: >>>> To help people avoid having to figure out what versions of make and >>>> binutils need to be supported document them explicitly. The version of >>>> binutils that had to be supported was mentioned in >>>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.ht >>>> ml >>>> as 2.17 recently. It was decided that the versions should instead be >>>> GNU binutils 2.16.1 and GNU Make 3.80 in >>>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02134.ht >>>> ml >>> >>> "decided" is a bit strong. I suggested these values. And while I'm >>> pretty certain that even plain make 3.80 will work, I'm in no way >>> sure plain 2.16.1 will (what I'm building with once in a while is some >>> 2.16.9x, and I can't say how many backports it has). So the >>> question really is - did you test that things build with these? >> >> Why would he have done, you suggested 2.16.1 with no hint that you thought >> it might not be a reasonable version to use. >> >> TBH having rejected Doug's original proposal I would have said it was up to >> you to specify the actual precise versions you think should be used, rather >> than making Doug guess and leading him down blind allies by making >> apparently authoritative suggestions which you secretly aren't actually >> sure about yourself. > > To be honest it didn't even occur to me that someone might > propose such a patch without verifying things actually build > (unless using more cautious wording). Also note that in the first > reply to the v1 patch I did refer to 2.16.9x (which imo has made > clear that that's the lowest one I ever tested with recently), i.e. > I don't think I've actively mislead him. > >> Anyway we could go round and round like this forever. What's wrong with >> starting with this as a baseline and bumping it if it turns out to be a >> problem in practice? > > Well, we certainly could (which would be in line with my second > reply to v1), just that I'm not sure how much value such a doc > addition then has. At the very least it should then say "no > lower than 2.16.1, something slightly newer may be needed" or > some such. > >>> Also I'm not sure 2.16.1 is going to be sufficient for ARM (it's >>> most definitely too old for ARM64). >> >> I suppose there is an implicit max(version, first version supporting arch). >> I don't think we can really go into the level of detail needed for per arch >> toolchain requirements. > > I'm afraid quite frequently "first version supporting arch" isn't > good enough. If we know otherwise for ARM64, that's certainly > fine. > >> I certainly don't know which version of either gcc or binutils is needed to >> build either ARM variant. > > Well, again - what's that documentation addition then good for? > > Jan > I withdraw the patch. I was simply trying to avoid the case where Konrad did some work and it was dependent on a newer version of binutils than was allowed in the tree but it was undocumented what version that was. I was also writing a patch to use some newer GNU Make bits and didn't know if that would be allowed. It seemed logical to want to clear up any ambiguity.
On 28/01/2016 13:47, Jan Beulich wrote: >>>> On 28.01.16 at 14:02, <ian.campbell@citrix.com> wrote: >> On Thu, 2016-01-28 at 05:49 -0700, Jan Beulich wrote: >>>>>> On 28.01.16 at 00:12, <cardoe@cardoe.com> wrote: >>>> To help people avoid having to figure out what versions of make and >>>> binutils need to be supported document them explicitly. The version of >>>> binutils that had to be supported was mentioned in >>>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.ht >>>> ml >>>> as 2.17 recently. It was decided that the versions should instead be >>>> GNU binutils 2.16.1 and GNU Make 3.80 in >>>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02134.ht >>>> ml >>> "decided" is a bit strong. I suggested these values. And while I'm >>> pretty certain that even plain make 3.80 will work, I'm in no way >>> sure plain 2.16.1 will (what I'm building with once in a while is some >>> 2.16.9x, and I can't say how many backports it has). So the >>> question really is - did you test that things build with these? >> Why would he have done, you suggested 2.16.1 with no hint that you thought >> it might not be a reasonable version to use. >> >> TBH having rejected Doug's original proposal I would have said it was up to >> you to specify the actual precise versions you think should be used, rather >> than making Doug guess and leading him down blind allies by making >> apparently authoritative suggestions which you secretly aren't actually >> sure about yourself. > To be honest it didn't even occur to me that someone might > propose such a patch without verifying things actually build > (unless using more cautious wording). Also note that in the first > reply to the v1 patch I did refer to 2.16.9x (which imo has made > clear that that's the lowest one I ever tested with recently), i.e. > I don't think I've actively mislead him. > >> Anyway we could go round and round like this forever. What's wrong with >> starting with this as a baseline and bumping it if it turns out to be a >> problem in practice? > Well, we certainly could (which would be in line with my second > reply to v1), just that I'm not sure how much value such a doc > addition then has. At the very least it should then say "no > lower than 2.16.1, something slightly newer may be needed" or > some such. > >>> Also I'm not sure 2.16.1 is going to be sufficient for ARM (it's >>> most definitely too old for ARM64). >> I suppose there is an implicit max(version, first version supporting arch). >> I don't think we can really go into the level of detail needed for per arch >> toolchain requirements. > I'm afraid quite frequently "first version supporting arch" isn't > good enough. If we know otherwise for ARM64, that's certainly > fine. > >> I certainly don't know which version of either gcc or binutils is needed to >> build either ARM variant. > Well, again - what's that documentation addition then good for? Ping? It doesn't matter exactly which version we choose as a minimum, but it *is* very important that the version is written down. Our README file is the correct place for this information to live. IMO, its also fine to say "For x86, GCC $X and Binutils $Y. For ARM, GCC $J and Binutils $K". ~Andrew
>>> On 10.02.16 at 21:36, <andrew.cooper3@citrix.com> wrote: > On 28/01/2016 13:47, Jan Beulich wrote: >>>>> On 28.01.16 at 14:02, <ian.campbell@citrix.com> wrote: >>> On Thu, 2016-01-28 at 05:49 -0700, Jan Beulich wrote: >>>>>>> On 28.01.16 at 00:12, <cardoe@cardoe.com> wrote: >>>>> To help people avoid having to figure out what versions of make and >>>>> binutils need to be supported document them explicitly. The version of >>>>> binutils that had to be supported was mentioned in >>>>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.ht >>>>> ml >>>>> as 2.17 recently. It was decided that the versions should instead be >>>>> GNU binutils 2.16.1 and GNU Make 3.80 in >>>>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02134.ht >>>>> ml >>>> "decided" is a bit strong. I suggested these values. And while I'm >>>> pretty certain that even plain make 3.80 will work, I'm in no way >>>> sure plain 2.16.1 will (what I'm building with once in a while is some >>>> 2.16.9x, and I can't say how many backports it has). So the >>>> question really is - did you test that things build with these? >>> Why would he have done, you suggested 2.16.1 with no hint that you thought >>> it might not be a reasonable version to use. >>> >>> TBH having rejected Doug's original proposal I would have said it was up to >>> you to specify the actual precise versions you think should be used, rather >>> than making Doug guess and leading him down blind allies by making >>> apparently authoritative suggestions which you secretly aren't actually >>> sure about yourself. >> To be honest it didn't even occur to me that someone might >> propose such a patch without verifying things actually build >> (unless using more cautious wording). Also note that in the first >> reply to the v1 patch I did refer to 2.16.9x (which imo has made >> clear that that's the lowest one I ever tested with recently), i.e. >> I don't think I've actively mislead him. >> >>> Anyway we could go round and round like this forever. What's wrong with >>> starting with this as a baseline and bumping it if it turns out to be a >>> problem in practice? >> Well, we certainly could (which would be in line with my second >> reply to v1), just that I'm not sure how much value such a doc >> addition then has. At the very least it should then say "no >> lower than 2.16.1, something slightly newer may be needed" or >> some such. >> >>>> Also I'm not sure 2.16.1 is going to be sufficient for ARM (it's >>>> most definitely too old for ARM64). >>> I suppose there is an implicit max(version, first version supporting arch). >>> I don't think we can really go into the level of detail needed for per arch >>> toolchain requirements. >> I'm afraid quite frequently "first version supporting arch" isn't >> good enough. If we know otherwise for ARM64, that's certainly >> fine. >> >>> I certainly don't know which version of either gcc or binutils is needed to >>> build either ARM variant. >> Well, again - what's that documentation addition then good for? > > Ping? It's not really clear at whom this ping was directed, the more that iirc the patch meanwhile got withdrawn. > It doesn't matter exactly which version we choose as a minimum, but it > *is* very important that the version is written down. Our README file > is the correct place for this information to live. I think it is quite relevant which version is to be picked: Anything older no-one could legitimately report issues against (and I would very much like to continue to be able to submit build fixes I find necessary on those two old boxes I keep for a reason), while stating something too old which even today we don't successfully build with would be pretty odd. Jan
On Thu, 2016-02-11 at 03:42 -0700, Jan Beulich wrote: > I think it is quite relevant which version is to be picked: Anything > older no-one could legitimately report issues against (and I would > very much like to continue to be able to submit build fixes I find > necessary on those two old boxes I keep for a reason), while > stating something too old which even today we don't successfully > build with would be pretty odd. So lets start with, for x86 whatever the older of the versions on the two boxes you refer to above and for ARM gcc 4.8 and binutils 2.24, which corresponds to what I happen to use for both arm32 and arm64 in my development environment. Those are IMHO reasonable starting points but obviously they aren't set in stone and can be easily adjusted later if necessary. Ian.
>>> On 11.02.16 at 11:59, <ian.campbell@citrix.com> wrote: > On Thu, 2016-02-11 at 03:42 -0700, Jan Beulich wrote: >> I think it is quite relevant which version is to be picked: Anything >> older no-one could legitimately report issues against (and I would >> very much like to continue to be able to submit build fixes I find >> necessary on those two old boxes I keep for a reason), while >> stating something too old which even today we don't successfully >> build with would be pretty odd. > > So lets start with, for x86 whatever the older of the versions on the two > boxes you refer to above and for ARM gcc 4.8 and binutils 2.24, which > corresponds to what I happen to use for both arm32 and arm64 in my > development environment. > > Those are IMHO reasonable starting points but obviously they aren't set in > stone and can be easily adjusted later if necessary. Okay, fine with me then (albeit as said I can't guarantee that the versions on those boxes [which are identical, it's just that one is a 32-bit one while the other is 64-bit] aren't heavily patched compared to their upstream originals). This would make binutils 2.16.91.0.5 gcc 4.1.2_20070115 Jan
diff --git a/README b/README index 1324c7c..f5bd429 100644 --- a/README +++ b/README @@ -36,8 +36,8 @@ release. Make sure you have all the following installed, either by visiting the project webpage or installing a pre-built package provided by your OS distributor: * GCC v4.1 or later - * GNU Make - * GNU Binutils + * GNU Make v3.80 or later + * GNU Binutils v2.16.1 or later * Development install of zlib (e.g., zlib-dev) * Development install of Python v2.3 or later (e.g., python-dev) * Development install of curses (e.g., libncurses-dev)
To help people avoid having to figure out what versions of make and binutils need to be supported document them explicitly. The version of binutils that had to be supported was mentioned in http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.html as 2.17 recently. It was decided that the versions should instead be GNU binutils 2.16.1 and GNU Make 3.80 in http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02134.html Signed-off-by: Doug Goldstein <cardoe@cardoe.com> --- README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)