From owner-svn-src-head@FreeBSD.ORG Wed May 28 15:28:26 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A7C3259; Wed, 28 May 2014 15:28:26 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2F0D22E5; Wed, 28 May 2014 15:28:25 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s4SFSLab010884; Wed, 28 May 2014 18:28:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4SFSLab010884 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s4SFSKkB010883; Wed, 28 May 2014 18:28:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 28 May 2014 18:28:20 +0300 From: Konstantin Belousov To: Warner Losh Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140528152820.GA3991@kib.kiev.ua> References: <5383522F.30108@freebsd.org> <20140527001811.3e9d3e8d@kalimero.tijl.coosemans.org> <05D1A11D-5985-42EA-84AD-209A8B51D391@bsdimp.com> <20140527093633.0a922e13@kalimero.tijl.coosemans.org> <85FABD2B-81BB-4E1A-B61E-4216A144A9DB@bsdimp.com> <20140527214038.17d00369@kalimero.tijl.coosemans.org> <13EB325C-3882-46AA-9B17-3BF19997C978@bsdimp.com> <20140528125027.6d0cc4fb@kalimero.tijl.coosemans.org> <5E038619-5921-4B7A-A4EE-D1E83614934B@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <5E038619-5921-4B7A-A4EE-D1E83614934B@bsdimp.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Baptiste Daroussin , src-committers@freebsd.org, Ian Lepore , svn-src-all@freebsd.org, Glen Barber , Nathan Whitehorn , svn-src-head@freebsd.org, Tijl Coosemans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 15:28:26 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote: >=20 > Then we disagree on this point. However, the disagreement here is > kinda foundational: to build a set of libraries or sys root, you have > to have a MACHINE_ARCH to make it work. Even in our current system, we > set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries > (note: we don?t do this for mips). This means that if we do grow x32 > support, we?ll need to grow a MACHINE_ARCH for it. That?s my point: > all ABIs have MACHINE_ARCH associated with them, and those are the > names users are used to specifying, and are the ones that are the most > natural for script writers to use. With nathan?s patches, we?re to the > point where those are used, though there?s also the option of using > the non-standard names if you want (e.g. amd64:32 instead of x32). > I am not sure if this comment would add anything to the discussion, but other build systems do not require MACHINE_ARCH. In our terms, other build systems are happy to build: i386 binary when MACHINE is amd64 and CFLAGS contains -m32; x32 binary when MACHINE is amd64 and CFLAGS contains -mx32. For HEAD and stable/10 we finally reached the point where -m32 works, on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least this is true for dependencies limited to the base system, and not to the ports (the later is since ports do not know about multiarch). It is limitation of our build that we require MACHINE_ARCH to build other natively supported ABI binary on the host. Ideally, the hacks that treat lib32 build as the cross-compilation would go away eventually. --wac7ysb48OaltWcw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJThgCUAAoJEJDCuSvBvK1B3/kQAJHMLD3bSzQPkNZ60/oge4Ot muZWe0NwKV48xhAM4ZfQjQiIuqwjuacOd8uhrkNGZ4kLpJ431y7Tx0WZ8TNfvZCV mgZDbW8jKreNmFEvvfdUKYah1OrbMwESdIrxtrmRKhqq1QaHJnjswKamFphyPIu/ L4Pl20OgA5YVS4hOuWNlVgXY/7ewjCSQKxcf3krwZnnPsU0CACizegfOZVCWYAeB TaqPgehCUNt2d3sWjPoDhjRdzO2ASir6wVaN4ReJUQUpTECg4nbk59ck97KBKpbz 8mqYK9rFhXUjvufbiBoTe9nCebB3ILbBWjtFSN6ykEiVMOg29PjAkrRL1JKNhGl8 OMw5S0kRUVLcDrvwl0WsZPrKzFLHHfNaX4bbGdW1vnbMY8NneJR/biyWnh5PO7wk FoV7fEfGZ9vMcCSJDbJdzHDaraljP21CAvYADAWYhQv7CNGUbU+Zi3gC2RlGsnJW y0+W0rH59IYhdVpFxcPOOQZtw49Gtjb13XZ/voUME4YZlzhmMH8RCBfeZd7n4tRd H6TbEMVp4SJj/EuKSGbpQ+TuOyqRaqsQI4cZTe9g6JVfB7Zxf0N0vPDJs7u+dz++ Nvx9N2FZ/I4+3ozYeaBjFiZlbvn2MDsxH7vUfhH5x1rdJkamQ1Ndjwj8IAk4NKU7 /+gYAi7vnVCEhQPIPsew =26aB -----END PGP SIGNATURE----- --wac7ysb48OaltWcw--