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=yes in make.conf > >> or src.conf. > >> > > > > Thank you. Long overdue, IMHO. > > > > Glen > > > > A slightly longer explanation of what I was thinking: > > - 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 the > 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 ?
>
> 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 most
> of the libraries are missing.
>
> 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.
>
> However, ld-elf32.so.1 does require special handling. I have something in
> mind that might make this moot though.
>
> 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.
pgpHpy6YF6ZdG.pgp
Description: PGP signature
