diff mbox

build: specify minimum versions of make and binutils

Message ID 1453136032-24899-1-git-send-email-cardoe@cardoe.com (mailing list archive)
State New, archived
Headers show

Commit Message

Douglas Goldstein Jan. 18, 2016, 4:53 p.m. UTC
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. Knowing that Jan got these versions from SLES10 I looked up the
version of GNU make from the same vintage (mid-2006) and landed on 3.81.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
 README | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Jan Beulich Jan. 18, 2016, 5:03 p.m. UTC | #1
>>> On 18.01.16 at 17:53, <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. Knowing that Jan got these versions from SLES10 I looked up the
> version of GNU make from the same vintage (mid-2006) and landed on 3.81.

I'm afraid that same SLE10 has been using binutils 2.16.9<n>.<something>
and make 3.80. While (still building Xen there once in a while) I'd probably
not be in big trouble if we decided we don't want to support that old an
environment anymore, I don't think we can just go and document higher
versions than we so far allowed. We'd first need to settle on where to
draw the line nowadays (which then likely would mean a gcc minimal
version bum too).

Jan
Douglas Goldstein Jan. 18, 2016, 5:21 p.m. UTC | #2
On 1/18/16 11:03 AM, Jan Beulich wrote:
>>>> On 18.01.16 at 17:53, <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. Knowing that Jan got these versions from SLES10 I looked up the
>> version of GNU make from the same vintage (mid-2006) and landed on 3.81.
> 
> I'm afraid that same SLE10 has been using binutils 2.16.9<n>.<something>
> and make 3.80. While (still building Xen there once in a while) I'd probably
> not be in big trouble if we decided we don't want to support that old an
> environment anymore, I don't think we can just go and document higher
> versions than we so far allowed. We'd first need to settle on where to
> draw the line nowadays (which then likely would mean a gcc minimal
> version bum too).
> 
> Jan
> 

Not a problem. I was just trying to take the situation from a guessing
game to be explicitly called out. I was documenting what my logic was
behind the version numbers I selected. I wasn't able to compare dates
with binutils because their repo goes from 2003 to 2011 [1]. So I went
back to SLES10's release date [2] and the GCC 4.1.0 release date [3] to
compare it with GNU make [4].

Honestly I'd be happy if we just drew a line in the sand so that its
clear what I need to test against when I submit patches. I don't really
care where the line is.


[1] https://ftp.gnu.org/gnu/binutils/
[2]
https://en.wikipedia.org/wiki/SUSE_Linux_Enterprise_Server#Version_history
[3] https://gcc.gnu.org/releases.html
[4] https://ftp.gnu.org/gnu/make/
Jan Beulich Jan. 19, 2016, 8:48 a.m. UTC | #3
>>> On 18.01.16 at 18:21, <cardoe@cardoe.com> wrote:
> On 1/18/16 11:03 AM, Jan Beulich wrote:
>>>>> On 18.01.16 at 17:53, <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. Knowing that Jan got these versions from SLES10 I looked up the
>>> version of GNU make from the same vintage (mid-2006) and landed on 3.81.
>> 
>> I'm afraid that same SLE10 has been using binutils 2.16.9<n>.<something>
>> and make 3.80. While (still building Xen there once in a while) I'd probably
>> not be in big trouble if we decided we don't want to support that old an
>> environment anymore, I don't think we can just go and document higher
>> versions than we so far allowed. We'd first need to settle on where to
>> draw the line nowadays (which then likely would mean a gcc minimal
>> version bum too).
> 
> Not a problem. I was just trying to take the situation from a guessing
> game to be explicitly called out. I was documenting what my logic was
> behind the version numbers I selected. I wasn't able to compare dates
> with binutils because their repo goes from 2003 to 2011 [1]. So I went
> back to SLES10's release date [2] and the GCC 4.1.0 release date [3] to
> compare it with GNU make [4].
> 
> Honestly I'd be happy if we just drew a line in the sand so that its
> clear what I need to test against when I submit patches. I don't really
> care where the line is.

Then how about 2.16.1 and 3.80 respectively as the initial line?

Jan
Douglas Goldstein Jan. 19, 2016, 7:24 p.m. UTC | #4
On 1/19/16 2:48 AM, Jan Beulich wrote:
>>>> On 18.01.16 at 18:21, <cardoe@cardoe.com> wrote:
>> On 1/18/16 11:03 AM, Jan Beulich wrote:
>>>>>> On 18.01.16 at 17:53, <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. Knowing that Jan got these versions from SLES10 I looked up the
>>>> version of GNU make from the same vintage (mid-2006) and landed on 3.81.
>>>
>>> I'm afraid that same SLE10 has been using binutils 2.16.9<n>.<something>
>>> and make 3.80. While (still building Xen there once in a while) I'd probably
>>> not be in big trouble if we decided we don't want to support that old an
>>> environment anymore, I don't think we can just go and document higher
>>> versions than we so far allowed. We'd first need to settle on where to
>>> draw the line nowadays (which then likely would mean a gcc minimal
>>> version bum too).
>>
>> Not a problem. I was just trying to take the situation from a guessing
>> game to be explicitly called out. I was documenting what my logic was
>> behind the version numbers I selected. I wasn't able to compare dates
>> with binutils because their repo goes from 2003 to 2011 [1]. So I went
>> back to SLES10's release date [2] and the GCC 4.1.0 release date [3] to
>> compare it with GNU make [4].
>>
>> Honestly I'd be happy if we just drew a line in the sand so that its
>> clear what I need to test against when I submit patches. I don't really
>> care where the line is.
> 
> Then how about 2.16.1 and 3.80 respectively as the initial line?
> 
> Jan
> 

Sounds great to me. Would you like me to resubmit or do you want to make
that change. I'm ok if you throw away my patch and author it yourself.
Whatever is easiest for you (or whoever commits it).
Jan Beulich Jan. 20, 2016, 8:09 a.m. UTC | #5
>>> On 19.01.16 at 20:24, <cardoe@cardoe.com> wrote:
> On 1/19/16 2:48 AM, Jan Beulich wrote:
>>>>> On 18.01.16 at 18:21, <cardoe@cardoe.com> wrote:
>>> On 1/18/16 11:03 AM, Jan Beulich wrote:
>>>>>>> On 18.01.16 at 17:53, <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. Knowing that Jan got these versions from SLES10 I looked up the
>>>>> version of GNU make from the same vintage (mid-2006) and landed on 3.81.
>>>>
>>>> I'm afraid that same SLE10 has been using binutils 2.16.9<n>.<something>
>>>> and make 3.80. While (still building Xen there once in a while) I'd probably
>>>> not be in big trouble if we decided we don't want to support that old an
>>>> environment anymore, I don't think we can just go and document higher
>>>> versions than we so far allowed. We'd first need to settle on where to
>>>> draw the line nowadays (which then likely would mean a gcc minimal
>>>> version bum too).
>>>
>>> Not a problem. I was just trying to take the situation from a guessing
>>> game to be explicitly called out. I was documenting what my logic was
>>> behind the version numbers I selected. I wasn't able to compare dates
>>> with binutils because their repo goes from 2003 to 2011 [1]. So I went
>>> back to SLES10's release date [2] and the GCC 4.1.0 release date [3] to
>>> compare it with GNU make [4].
>>>
>>> Honestly I'd be happy if we just drew a line in the sand so that its
>>> clear what I need to test against when I submit patches. I don't really
>>> care where the line is.
>> 
>> Then how about 2.16.1 and 3.80 respectively as the initial line?
> 
> Sounds great to me. Would you like me to resubmit or do you want to make
> that change. I'm ok if you throw away my patch and author it yourself.
> Whatever is easiest for you (or whoever commits it).

I'd prefer if you re-submitted.

Jan
diff mbox

Patch

diff --git a/README b/README
index 1324c7c..5198456 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.81 or later
+    * GNU Binutils v2.17 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)