[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.