From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCH v2] build: specify minimum versions of make and binutils Date: Thu, 28 Jan 2016 08:39:00 -0600 Message-ID: <56AA2804.5050900@cardoe.com> References: <1453936359-10115-1-git-send-email-cardoe@cardoe.com> <56AA1C8502000078000CC01A@prv-mh.provo.novell.com> <1453986140.26591.81.camel@citrix.com> <56AA29F502000078000CC08E@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0790922641071115467==" Return-path: In-Reply-To: <56AA29F502000078000CC08E@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Campbell Cc: KeirFraser , Tim Deegan , Ian Jackson , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============0790922641071115467== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uKaIo6JggoCxVrpXvUfDqpD0fdDb6O9NJ" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uKaIo6JggoCxVrpXvUfDqpD0fdDb6O9NJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/28/16 7:47 AM, Jan Beulich wrote: >>>> On 28.01.16 at 14:02, wrote: >> On Thu, 2016-01-28 at 05:49 -0700, Jan Beulich wrote: >>>>>> On 28.01.16 at 00:12, 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= =2Eht=20 >>>> ml=20 >>>> 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= =2Eht=20 >>>> ml=20 >>> >>> "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 som= e >>> 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 tho= ught >> 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, r= ather >> than making Doug guess and leading him down blind allies by making >> apparently authoritative suggestions which you secretly aren't actuall= y >> sure about yourself. >=20 > 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. >=20 >> Anyway we could go round and round like this forever. What's wrong wit= h >> starting with this as a baseline and bumping it if it turns out to be = a >> problem in practice? >=20 > 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. >=20 >>> 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 a= rch). >> I don't think we can really go into the level of detail needed for per= arch >> toolchain requirements. >=20 > I'm afraid quite frequently "first version supporting arch" isn't > good enough. If we know otherwise for ARM64, that's certainly > fine. >=20 >> I certainly don't know which version of either gcc or binutils is need= ed to >> build either ARM variant. >=20 > Well, again - what's that documentation addition then good for? >=20 > Jan >=20 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. --=20 Doug Goldstein --uKaIo6JggoCxVrpXvUfDqpD0fdDb6O9NJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWqigGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUC94P/3KM/jwKMzng0xP51Y3rvlFb ZnK+xPVBzMPMONR71eXQVxPQilaDKThKBKYN6ySBVPnBr9Oskoaz6WqmrxXpDb9L 9H6ubptVuR54szQBVKjN9SoN7HDtt2gVv0FnDCMuaBgB+hP0dQ1GT+OnhjvjX9wm h/uGUMsZnzLELhEcwKqm1TFRrElsn5MEMVPl31kyxaRl2KhJbo0UPlIE6ryfhAjU fd41otDlPTFUQrj0CMGBaVZJdaoU1zTU75dHwLY3K0oms4nAefj0I9wk3dLZ6oev 9FFzSazaj9GjCQNtiUuv3xVo1qQ6c7pb15S8QdRmEwIrVBggD6bk+PNqwmwTxwg3 T6yTGJKgioFvSZXb9bf6Mrhl+9UvjFpJn4q10XEZBlTcEFVmWbYhm+EC1xk14SU2 bV2QbUdELEbJDDrkAen/e/b8wjj5IwPqbXzbkLUICyHVOBxP2YKxukiUuz4zh8qb L1GWhcLUXzCQFFhiLdlVTEHjzXb+HQl+mxnFqPRXmoW9qgOmKvJw2bpNZr9UpIso 218sDRqqAmMEjLoaoM2qelDfFq0UuW7FEO8u7bjPxOJeSvcOg7gEG2Y210EzUTBC VEk1SmE79RLkre1Ld1MPogfsbMuO8oa/9OAl3y5S4dfVk/uIgq4NpMmwbCzv+HBs sG+uSn3DfXGYm0f3GJLH =/Eqa -----END PGP SIGNATURE----- --uKaIo6JggoCxVrpXvUfDqpD0fdDb6O9NJ-- --===============0790922641071115467== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0790922641071115467==--