Re: svn commit: r258672 - in head: . share/mk
On Wed, Nov 27, 2013 at 8:00 AM, Tijl Coosemans wrote: > On Tue, 26 Nov 2013 22:34:30 -0800 Peter Wemm wrote: >> 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. >> - We don't build them properly - we invent cpu flags etc. >> >> 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. > > Ugh, please revert this. You forgot about Wine. Done, but nothing prevented you from adding WITH_LIB32=yes yourself, or doing a 'make build32/install32' after buildworld/installworld. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r258672 - in head: . share/mk
On Tue, 26 Nov 2013, Peter Wemm wrote: [snip] > 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. sorry for my possible ignorance, but aren't compat6 suspected to non-closed (probablly non-trivial) security concerns? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r258672 - in head: . share/mk
On Nov 27, 2013, at 12:34 AM, Peter Wemm wrote: > On 11/26/13, 9:03 PM, Glen Barber wrote: >> On Wed, Nov 27, 2013 at 04:54:24AM +, 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. > - We don't build them properly - we invent cpu flags etc. > > 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… > FWIW, this would break 3rd-party software I use on amd64 that was only provided as i386 binaries. Guy ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r258672 - in head: . share/mk
On 11/26/13 23:54, 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. > > Modified: > head/UPDATING > head/share/mk/bsd.own.mk > If you decide to keep this change, can you add LIB32 stuff to optional obsoletes? Otherwise people will be left with rotting outdated lib32 directories. Thanks! - Nikolai Lifanov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r258672 - in head: . share/mk
On Tue, 26 Nov 2013 22:34:30 -0800 Peter Wemm wrote: > 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. > - We don't build them properly - we invent cpu flags etc. > > 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. Ugh, please revert this. You forgot about Wine. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r258672 - in head: . share/mk
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 +, 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
Re: svn commit: r258672 - in head: . share/mk
on 27/11/2013 08:34 Peter Wemm said the following:
> On 11/26/13, 9:03 PM, Glen Barber wrote:
>> On Wed, Nov 27, 2013 at 04:54:24AM +, 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.
Do this change and this point make sense if everyone building virtualbox (and
perhaps running it) has to install lib32 anyway?
pre-everything::
.if ${ARCH} == "amd64"
.if !exists(/usr/lib32/libc.so)
@${ECHO} 'Requires 32-bit libraries installed under /usr/lib32.'
@${ECHO} 'Do: cd /usr/src; make build32 install32; /etc/rc.d/ldconfig
restart'
@${FALSE}
.endif
.endif
Just in case, I have no clue why this is required.
> - We don't build them properly - we invent cpu flags etc.
>
> 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...
>
--
Andriy Gapon
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r258672 - in head: . share/mk
On 11/26/13, 9:03 PM, Glen Barber wrote: > On Wed, Nov 27, 2013 at 04:54:24AM +, 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. - We don't build them properly - we invent cpu flags etc. 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... -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" signature.asc Description: OpenPGP digital signature
Re: svn commit: r258672 - in head: . share/mk
On Wed, Nov 27, 2013 at 04:54:24AM +, 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 pgpHDXVS2wCZM.pgp Description: PGP signature
svn commit: r258672 - in head: . share/mk
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. Modified: head/UPDATING head/share/mk/bsd.own.mk Modified: head/UPDATING == --- head/UPDATING Wed Nov 27 04:34:44 2013(r258671) +++ head/UPDATING Wed Nov 27 04:54:23 2013(r258672) @@ -31,6 +31,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +20131126: + WITH_LIB32 has been changed to WITHOUT_LIB32 by default. You + can set WITH_LIB32=yes in make.conf or src.conf, or if you need + to do a quick 32 bit library build you can do a 'make build32' + and 'make install32' as a separate step AFTER doing a + buildworld/installworld. + 20131108: The WITHOUT_ATF build knob has been removed and its functionality has been subsumed into the more generic WITHOUT_TESTS. If you were Modified: head/share/mk/bsd.own.mk == --- head/share/mk/bsd.own.mkWed Nov 27 04:34:44 2013(r258671) +++ head/share/mk/bsd.own.mkWed Nov 27 04:54:23 2013(r258672) @@ -303,7 +303,6 @@ __DEFAULT_YES_OPTIONS = \ LDNS \ LDNS_UTILS \ LEGACY_CONSOLE \ -LIB32 \ LIBPTHREAD \ LIBTHR \ LOCALES \ @@ -369,6 +368,7 @@ __DEFAULT_NO_OPTIONS = \ GPL_DTC \ HESIOD \ INSTALL_AS_USER \ +LIB32 \ LLDB \ NAND \ OFED \ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
