Re: NetBSD base gcc & libatomic
On Sat, Dec 05, 2020 at 09:03:30PM +0100, Rhialto wrote: > On Fri 04 Dec 2020 at 15:42:43 +0100, Riccardo Mottola wrote: > > on x86-32, I noticed our compiler emits calls to atomic functions, but > > does not ship libatomic, which is available only as an "addon" in pkgsrc. > > I think the base compiler should be consistent and either ship libraries > > it uses or do not use. > > Gcc from pkgsrc then is free to pull libatomic in instead. > > > > What do you think? > > In pkgsrc-users I posted a mail about compiling > pkgsrc/wip/sdl-hercules-hyperion on NetBSD/i386, where gcc generated > calls to (at least) __sync_fetch_and_add_8 and > __atomic_compare_exchange_8. I installed libatomic from pkgsrc, but it > didn't appear to provide any functions starting with __sync (according > to nm). -march=i586 could/should work for i386 unless the real hardware is really old or the emulation doesn't support it. Onno
Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly
On Mon, Mar 13, 2017 at 05:11:59PM +0100, Marco Beishuizen wrote: > On Mon, 13 Mar 2017, the wise co...@sdf.org wrote: > > > Mozilla maintains an 'Extended Support Release' which has security fixes > > backported to it, so it will be a better choice for such cases. > > Currently, it is www/firefox45 - it is updated whenever www/firefox is, > > containing fixes for the same vulnerabilities. Soon firefox52 (current > > non-ESR version) will become ESR. > > I'm experiencing the same problems on the ESR versions. So I'm guessing it's > a specific i386 problem and not a version problem. It's also not a recent > problem but happening for several months now. FWIW, I'm running current on a pretty old (Asus P4B533, P4 2.26GHz 2Gb mem) machine. Had one (known) problem with FF 51 that created coredumps at exit time. That bug is fixed in FF 52. Another problem with certain recent FF versions (the ones after FF 45 where gfx.xrender.enabled changed to false by default) was that when visiting a site with huge images the xorg process suddenly got to (and stayed at) 80% CPU or so. At the moment both FF 45 (compiled with GTK2) and FF 52 (compiled with GTK3) work fine for me on everything I throw at it. Onno
Re: nspluginwrapper and libflashsupport updates for adobe-flash-plugin
On Thu, Oct 29, 2015 at 12:12:27PM -0600, Roy Bixler wrote: > On Mon, Oct 26, 2015 at 09:59:13PM +0530, Mayuresh wrote: > > On Mon, Oct 26, 2015 at 09:42:11AM -0600, Roy Bixler wrote: > > > I had the same problem and found that starting up dbus and avahidaemon > > > solved it. With older versions of Firefox, this wasn't necessary. > > > I'd be interested to see if there are other solutions to this, since > > > I'd rather not run dbus/avahi. > > > > Entirely agree. It's scary to do so much for a web browser. Can someone > > confirm this hypothesis? > > > > If true, shouldn't it be a captured as a dependency? > > I notice that those are dependencies, but only indirectly. The > problem direct dependency is pulseaudio, which has dbus and avahi as > its dependencies. I wonder if it's possible to build a recent Firefox > using some other audio backend. It seems worthwhile, since pulseaudio > is a real CPU hog and it might also eliminate the need for dbus/avahi. Yes, it's possible to use the oss backend of firefox. See pkg/50306 (http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50306) for the stuff I've been using. Depending on the firefox version you might wanna change/add some of the media.* defaults via about:config. Onno
