Date: Wed, 27 Nov 2013 09:50:51 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Peter Wemm <peter@wemm.org> Cc: svn-src-head@freebsd.org, Glen Barber <gjb@FreeBSD.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r258672 - in head: . share/mk Message-ID: <20131127075051.GU59496@kib.kiev.ua> In-Reply-To: <52959276.7070803@wemm.org> References: <201311270454.rAR4sOqI004103@svn.freebsd.org> <20131127050358.GG1710@glenbarber.us> <52959276.7070803@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131127075051.GU59496>