From owner-svn-src-all@FreeBSD.ORG Wed Nov 27 07:51:03 2013 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 2C97E1AE; Wed, 27 Nov 2013 07:51:03 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 967A52DA2; Wed, 27 Nov 2013 07:51:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAR7oqlA014733; Wed, 27 Nov 2013 09:50:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAR7oqlA014733 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAR7opq2014727; Wed, 27 Nov 2013 09:50:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Nov 2013 09:50:51 +0200 From: Konstantin Belousov To: Peter Wemm Subject: Re: svn commit: r258672 - in head: . share/mk Message-ID: <20131127075051.GU59496@kib.kiev.ua> References: <201311270454.rAR4sOqI004103@svn.freebsd.org> <20131127050358.GG1710@glenbarber.us> <52959276.7070803@wemm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ryZWRk5DZTcwGpL9" Content-Disposition: inline In-Reply-To: <52959276.7070803@wemm.org> User-Agent: Mutt/1.5.22 (2013-10-16) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@freebsd.org, Glen Barber , svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 07:51:03 -0000 --ryZWRk5DZTcwGpL9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 26, 2013 at 10:34:30PM -0800, Peter Wemm wrote: > On 11/26/13, 9:03 PM, Glen Barber wrote: > > On Wed, Nov 27, 2013 at 04:54:24AM +0000, Peter Wemm wrote: > >> Author: peter > >> Date: Wed Nov 27 04:54:23 2013 > >> New Revision: 258672 > >> URL: http://svnweb.freebsd.org/changeset/base/258672 > >> > >> Log: > >> At great personal risk, change the default for LIB32 from yes to no.= As > >> mentioned in UPDATING, you can even do it as an as-needed operation = after > >> doing a buildworld/installworld. You can set WITH_LIB32=3Dyes in ma= ke.conf > >> or src.conf. > >> > >=20 > > Thank you. Long overdue, IMHO. > >=20 > > Glen > >=20 >=20 > A slightly longer explanation of what I was thinking: >=20 > - There's a new round of 'make -j' problems lurking in there. We are > missing chunks of the ordering glue that cause libraries to be built in t= he > right order when they depend on each other. > - It's a waste of cpu time for the usual case, particularly for the 11.x > cycle for the next 1-2 years. Why ? > - We don't build them properly - we invent cpu flags etc. What do you mean there ? Do you reference the fact that lib32 build on amd64 assumes sse2 and all previous coprocessor extensions ? >=20 > The usual use case for 32 bit binaries seems to be: > - running a 32 bit chroot or jail - this is unaffected. > - running old binaries, usually from 4.x or 6.x when the 64 bit port was > really green - WITH_LIB32 doesn't actually help much with this because mo= st > of the libraries are missing. >=20 > It seems more likely we can do a better job with packages. With some > massaging, we should be able to use the compat-6.x/i386 libraries as-is, = and > solve the "old 4.x/6.x binary" issue in one go. >=20 > However, ld-elf32.so.1 does require special handling. I have something in > mind that might make this moot though. >=20 > I suspect I've made the powerpc folks angry though... I disagree with the change. It was not discussed, and the motivation presented ('the build has bugs') is not valid for removing a useful feature. All other OSes I am aware of implement multi-arch fully. For 10/11, we have quite good compat32 layer for non-managing interfaces, and have user-mode compilation environment. I think that the route to go forward is to have multi-arch for ports, or at least, enable to have 32bit ports installation on 64bit host. I think that this is step backward. --ryZWRk5DZTcwGpL9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlaRaAAoJEJDCuSvBvK1BSNsP/iK+Ag9IsZh0i35y7nG8K2wd lg/L+qgL8bH2DWuNZMwhHQwM79M/C80w8jF0x9AWBZp8Y3RQwdNzecYnbPQbJ4v7 2xU9j8FyHgVYROwp8oTwKlZLltbrXlb0RfafFCas57eRFOq+m9OyncxITYwhucBS mWxuLyqaliBWDiI1ErFmPXhygsEEaCV74lZmZlIpXeeLt6HKG2K5nSsEZNUbRbVB tEjr/MroIHTQXeir7N8IHCkupuAoXfpKtYWaHhStcPVXcHIicBsvn9SnGRZv1joL w3WCe/Sb2k+i1fzuwr/UHesFqxO/4LjXkMWrwWxv+NMr4ChnJJgxFLDI/4qo1qNx xbWkL9u0gkJdZF/LCgHueJ6to52JM3yOnzrDl7sNnStua7kn7OD6fchKTZBz1LTx EpqNBKwNEFJdOAlEBWYAH1H3Y1YtCsslF0GnanlA+Gi9kG6ymOL62SsxBhZSg2pJ GhCazNYBviwSc4Ji+tu8ftURRPGRS6vIC73rlpdLjVbFHBMqqTkQuHcTGWb2duXC IciEoloMPnb/QwvWU7Zj7mKBDwfwDmiXKDN4CfanFEShgU5BMWhAQmifBBaX4GMy AEaIaGG8o1mH092S411MRwwGNMexDVxdxTPwj3e4kJOYHXomxvUalt5Ooh3r2YDA FQEG5pbkwwxcfiY2AihL =RwfC -----END PGP SIGNATURE----- --ryZWRk5DZTcwGpL9--