Right now, devel/glib20 port is built with slower, mutex-based variant of g_atomic_whatever routines, instead of assembler-based ones. This is slower and possibly unreliable, as there are semantical differences between the two (mutex-based versions may deadlock). This breaks audio/ardour and possibly other applications. Fix would be to patch the configure script to set host_cpu to "i486" instead of "i386". This would break glib20 on a real i386, though.
Responsible Changed From-To: freebsd-ports-bugs->gnome Over to maintainer(s).
FYI: We don't have to worry about i386, since it's not support by FreeBSD. As for gets it compiled with mutex-based implementation of atomic ops, I can't comment on it. I don't know anything about it. Although it does sound good. I will let marcus, bland or whomever to take care of it. Cheers, Mezz -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
State Changed From-To: open->closed Functionality has been restored.
marcus 2008-11-25 18:52:50 UTC FreeBSD ports repository Modified files: devel/glib20 Makefile Log: Restore the ability to compile with optimized assembler code. PR: 129088 Revision Changes Path 1.154 +2 -1 ports/devel/glib20/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
On 1125T1220, Jeremy Messenger wrote: > FYI: We don't have to worry about i386, since it's not support by FreeBSD. > > As for gets it compiled with mutex-based implementation of atomic ops, I > can't comment on it. I don't know anything about it. Although it does > sound good. I will let marcus, bland or whomever to take care of it. Thank you; fix works just fine. -- If you cut off my head, what would I say? Me and my head, or me and my body?