From owner-svn-src-all@FreeBSD.ORG Thu May 29 01:53:36 2014 Return-Path: Delivered-To: svn-src-all@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 9E8809F1; Thu, 29 May 2014 01:53:36 +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 3D3AF2C13; Thu, 29 May 2014 01:53:36 +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 s4T1rVcA046705; Thu, 29 May 2014 04:53:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4T1rVcA046705 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s4T1rU1X046704; Thu, 29 May 2014 04:53:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 May 2014 04:53:30 +0300 From: Konstantin Belousov To: Warner Losh Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140529015330.GG3991@kib.kiev.ua> References: <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> <20140528154728.GB3991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PpAOPzA3dXsRhoo+" 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: Thu, 29 May 2014 01:53:36 -0000 --PpAOPzA3dXsRhoo+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 28, 2014 at 01:53:28PM -0600, Warner Losh wrote: >=20 > On May 28, 2014, at 9:47 AM, Konstantin Belousov wr= ote: >=20 > > On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote: > >>=20 > >> On May 28, 2014, at 9:28 AM, Konstantin Belousov = wrote: > >>=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 mo= st > >>>> natural for script writers to use. With nathan?s patches, we?re to t= he > >>>> 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 lea= st > >>> 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 t= hat > >>> 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. >=20 > As far as I can tell, that?s the only reason we?re doing it.. But it is = a critically important reason... >=20 > > 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. >=20 > lib32 uses -m32 and some other flags to achieve its ends. So it doesn?t c= reate a full i386 compiler, etc. It just uses the amd64 one with special fl= ags/args. So I don?t think it requires a full-fledged cross-build environme= nt, or I misunderstand what you mean by that phrase. We install the headers for the MACHINE_ARCH into the compat32 build tree, and use them instead of the target MACHINE headers. The fact that -m32 works as the cross-compiler just saves the build time. >=20 > But none of this changes the fact that we have a unique MACHINE_ARCH valu= e per ABI. >=20 > Warner --PpAOPzA3dXsRhoo+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJThpMaAAoJEJDCuSvBvK1Bi+4P/jdQaU0MKqPlnvqsw4gIo7Cl 3t7UAhdstmhdXCVmxExkAC3jt/4bxo/DJgf9LTTB3KIuOvTk3oas5SmfKGPcObl2 230+zoTAsAtAFFDLDwcOkpHMS7CGf13t7QuqWNbp6G6OdxGrdWdcFEYSycVlIGJ8 YWg/icRyGVnG6YBFjrb5oam+sOJICfV77jN6HxO+3DztZi7DRhctRqy4rzPQq3ma bL2SlBVwaB+cR3apoN5LYF7Z3NgI7H2S6ro/0SmHwSTcaS59uiaMpsTLXUDPRcwP J7QAwMm8z1P1j4+Zdqdr8fMoJrM1fsc7cfPUQ8JA0DEWn+pns1Sq0vkxOgWMV5Do ulaHUZVJktx5S8Hv8xA//V8drTwTrvn7R9Sb5hKPhEQfwy4GYiRf+HBnzCYugXMY zWwqzQxqAnBmB86Uivq1G1Al/CJo48YfCH2aoJVvdmrCr61ArHqE98Yn4pVGeRv3 gE3HOeNC4rGfZw1/p0lHbmjwG7+ZU8xP/hgb9TNmoybjTbMqYcFLiGP3oTSZ/gmJ 20OcMhF0LZlOFC0+/dMIPwYNDOrWY6XdRRZRUQRO2gMVLpQ6m6jIA2owQ5koSEbM XQNACblvF0Pem8bNEBERe4PGLiezSathDAt2rQTTGVykIsOw177VjJr3I2M7SDvb nkgfavv1ODH4xGBeyOyZ =TWjf -----END PGP SIGNATURE----- --PpAOPzA3dXsRhoo+--