Re: HEADS UP: librt revert
On Sun, Mar 23, 2014 at 05:05:06PM -0400, STeve Andre' wrote:
> >If you've built a tree with librt, you want to
> ># rm -f /usr/lib/librt.a
>
> Shouldn't that be librt*a to get rid of librt_p.a too?
Thanks to tedu@ there's now
rm -f /usr/lib/librt{,_p}.a
in faq/current.html
Re: HEADS UP: librt revert
On Sun, Mar 23, 2014 at 05:05:06PM -0400, STeve Andre' wrote: > On 03/23/14 14:34, Marc Espie wrote: > >kili@ just committed a revert of the librt addition in src and corresponding > >patches in ports. > > > >If you've built a tree with librt, you want to > ># rm -f /usr/lib/librt.a > > Shouldn't that be librt*a to get rid of librt_p.a too? Yep, it should. Though it's less likely to cause issues...
Re: HEADS UP: librt revert
On 03/23/14 14:34, Marc Espie wrote: kili@ just committed a revert of the librt addition in src and corresponding patches in ports. If you've built a tree with librt, you want to # rm -f /usr/lib/librt.a Shouldn't that be librt*a to get rid of librt_p.a too? --STeve Andre'
Re: HEADS UP: librt revert
On Sun, Mar 23, 2014 at 10:46:08PM +0400, Loganaden Velvindron wrote: > On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie wrote: > > kili@ just committed a revert of the librt addition in src and > > corresponding > > patches in ports. > > > > If you've built a tree with librt, you want to > > # rm -f /usr/lib/librt.a > > > > This lib was added to facilitate porting software, as posix asks for it. > > but since it's only a stub, it was only added as a static library. No-one > > would approve a shared library, as that would waste space. > > > > Unfortunately, libtool (ours and gnu's) don't cope well with static-only > > libraries. The untested commit of librt in source broke the ports tree. > > > > Specifically, programs such as x11/vlc, multimedia/xine-lib, or lang/php > > would no longer build (all 3 are using mutant versions of gnu libtool). > > > > It's possible further breakage would happen, but those 3 were broken. > > > > After almost a week (!), there has been exactly zero activity to fix the > > breakage. No-one volunteered to do the requisite patches, and well, > > these ports are not exactly low profile, we need a ports tree in working > > condition to be able to conduct other work (such as the pending update to > > perl, or some other clean-up work). > > That's very sad. I get the impression that there aren't many active > developers (?) No, it's more a question of people being busy with other things at times. There is a flurry of important activity in preparation for various things. It's one of those times when having a tree that works is important. A week is an fairly long time for the tree to stay broken, in OpenBSD terms. The revert is a pain, but much less pain than figuring out what to do to get the affected ports to build again in a clean fashion. And again, the concerned people were not available to do timely fixes. As for myself, for instance, I'm busy with perl 5.18, and there are some interesting new features (randomization of the hash function) that have exposed other "interesting problems" in our libtool... you can't wage a war on several fronts. The librt breakage was fairly distracting for a group of people that are working on other stuff. After a while, you just have to do something that lets the tree build.
Re: HEADS UP: librt revert
On Sun, Mar 23, 2014 at 10:46 PM, Loganaden Velvindron wrote: > On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie wrote: >> kili@ just committed a revert of the librt addition in src and corresponding >> patches in ports. >> >> If you've built a tree with librt, you want to >> # rm -f /usr/lib/librt.a >> >> This lib was added to facilitate porting software, as posix asks for it. >> but since it's only a stub, it was only added as a static library. No-one >> would approve a shared library, as that would waste space. >> >> Unfortunately, libtool (ours and gnu's) don't cope well with static-only >> libraries. The untested commit of librt in source broke the ports tree. >> >> Specifically, programs such as x11/vlc, multimedia/xine-lib, or lang/php >> would no longer build (all 3 are using mutant versions of gnu libtool). >> >> It's possible further breakage would happen, but those 3 were broken. >> >> After almost a week (!), there has been exactly zero activity to fix the >> breakage. No-one volunteered to do the requisite patches, and well, >> these ports are not exactly low profile, we need a ports tree in working >> condition to be able to conduct other work (such as the pending update to >> perl, or some other clean-up work). > > That's very sad. I get the impression that there aren't many active > developers (?) Sorry, this shouldn't have been sent :-( Please ignore. > > >> >> So for now, the librt experiment got reverted. Maybe temporarily (). >> If people really want it in, they had better be willing to figure out >> how to fix the libtool breakage first... >> > > > > -- > This message is strictly personal and the opinions expressed do not > represent those of my employers, either past or present. -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: HEADS UP: librt revert
On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie wrote: > kili@ just committed a revert of the librt addition in src and corresponding > patches in ports. > > If you've built a tree with librt, you want to > # rm -f /usr/lib/librt.a > > This lib was added to facilitate porting software, as posix asks for it. > but since it's only a stub, it was only added as a static library. No-one > would approve a shared library, as that would waste space. > > Unfortunately, libtool (ours and gnu's) don't cope well with static-only > libraries. The untested commit of librt in source broke the ports tree. > > Specifically, programs such as x11/vlc, multimedia/xine-lib, or lang/php > would no longer build (all 3 are using mutant versions of gnu libtool). > > It's possible further breakage would happen, but those 3 were broken. > > After almost a week (!), there has been exactly zero activity to fix the > breakage. No-one volunteered to do the requisite patches, and well, > these ports are not exactly low profile, we need a ports tree in working > condition to be able to conduct other work (such as the pending update to > perl, or some other clean-up work). That's very sad. I get the impression that there aren't many active developers (?) > > So for now, the librt experiment got reverted. Maybe temporarily (). > If people really want it in, they had better be willing to figure out > how to fix the libtool breakage first... > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
HEADS UP: librt revert
kili@ just committed a revert of the librt addition in src and corresponding patches in ports. If you've built a tree with librt, you want to # rm -f /usr/lib/librt.a This lib was added to facilitate porting software, as posix asks for it. but since it's only a stub, it was only added as a static library. No-one would approve a shared library, as that would waste space. Unfortunately, libtool (ours and gnu's) don't cope well with static-only libraries. The untested commit of librt in source broke the ports tree. Specifically, programs such as x11/vlc, multimedia/xine-lib, or lang/php would no longer build (all 3 are using mutant versions of gnu libtool). It's possible further breakage would happen, but those 3 were broken. After almost a week (!), there has been exactly zero activity to fix the breakage. No-one volunteered to do the requisite patches, and well, these ports are not exactly low profile, we need a ports tree in working condition to be able to conduct other work (such as the pending update to perl, or some other clean-up work). So for now, the librt experiment got reverted. Maybe temporarily (). If people really want it in, they had better be willing to figure out how to fix the libtool breakage first...
