From owner-svn-src-all@FreeBSD.ORG Wed May 28 15:47:33 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52146AFC; Wed, 28 May 2014 15:47:33 +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 CBCE224D9; Wed, 28 May 2014 15:47:32 +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 s4SFlSLW016504; Wed, 28 May 2014 18:47:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4SFlSLW016504 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s4SFlSq5016503; Wed, 28 May 2014 18:47:28 +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:47:28 +0300 From: Konstantin Belousov To: Warner Losh Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140528154728.GB3991@kib.kiev.ua> References: <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> <20140528152820.GA3991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: 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-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 15:47:33 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote: >=20 > On May 28, 2014, at 9:28 AM, Konstantin Belousov wr= ote: >=20 > > 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). > >>=20 > >=20 > > 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. > >=20 > > 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). > >=20 > > 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. >=20 > I doubt it. The MACHINE_ARCH is used to select which files to build. Do I understand you right that the comment references e.g. a selection of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion into the build ? If yes, I cannot disagree with the statement. My note was about our build system which currently requires full-fledged cross-build to even create i386 binary on amd64 vs. other builds which consider this as a (often minor) variations of the host target. Sure, some variances must be allowed, e.g. to select proper .S file for the ABI, but we do not need cross-build to get i386 on amd64. --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJThgUPAAoJEJDCuSvBvK1Bbe4QAJDH1hKh9V4H/9aU4CyfR9YE bOiZ1ZkoCTs2zvkPyJyQ53GWXnAPZLDTo0pcljeY86riSguTCOVG7aKDFJf4TkrB eeK5e31BCbTK38Hz/M8I+fYv86FqcT41bn0uTAIWCdAltdghh/9pWYG55kNIg94P INp4fa3hauBqW8ZpIHBUjq7ECpORpeF7I1Jf0B7Xxk7aKN7ClqyRkXidsJ3R4MBf MvZxVzIauGzyRC3uLGoTuKWMv29fRoZVPTktpecXSZVrP+LQU8tlyfHpNbeh1c1Z mEQLy4L8/VIr6ThwFXQIflYeiDrGIYdmdUO1y5LUjcSVuhOTVHbiMnZ9xurAM/T+ k1JKw/NOohI0KrzGtqLnAQ+ujfr1oHssNv0wdbsyJeogcwkoN2uPSPTzmznjBQ2i D/NNWF8GGlRiAzQYOWdDoXUwjauh9TxFrNhXmxVGWQaG2WqvwQZkPzyYy46b8VTg Xeg2toBnzW218ClZir9pNCNjtPqcn+EXvKCq/iiBscQQPmjYlW8im2WYpTCHR12H NGIGPAz7Ja/3CeIwyn3IRV3v7DyOWAYU/HhANoMrdchJu5vm9z7TG6jVu7skWg0T GORMGasuwMpyKwNRWMKedb4EAa7SGEnKtIb/tKDxSY4mOjwU5LPZoq/At21O1OoU JHgJ2a+NR/m+ADvxYnlW =GH1I -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o--