[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] build: specify minimum versions of make and binutils
>>> On 10.02.16 at 21:36, <andrew.cooper3@xxxxxxxxxx> wrote: > On 28/01/2016 13:47, Jan Beulich wrote: >>>>> On 28.01.16 at 14:02, <ian.campbell@xxxxxxxxxx> wrote: >>> On Thu, 2016-01-28 at 05:49 -0700, Jan Beulich wrote: >>>>>>> On 28.01.16 at 00:12, <cardoe@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |