Date: Mon, 27 Jul 2009 14:19:59 +0000 From: "b. f." <bf1783@googlemail.com> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-multimedia@freebsd.org, thomas.e.zander@googlemail.com, freebsd-ports@freebsd.org Subject: Re: FreeBSD Port: mplayer-0.99.11_14 Message-ID: <d873d5be0907270719o14febae4v1fb134fd7b4f81ab@mail.gmail.com> In-Reply-To: <4A6D801F.8020607@icyb.net.ua> References: <d873d5be0907242220v5597a4c5m54947fbaafc5107f@mail.gmail.com> <4A6D801F.8020607@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/27/09, Andriy Gapon <avg@icyb.net.ua> wrote: > Just curious, can't newer GCC(s) from ports be used to build those mplayer > snapshots? > We have: > /usr/ports/lang/gcc42 <- 4.2.5 > /usr/ports/lang/gcc43 <- 4.3.4 > /usr/ports/lang/gcc44 <- 4.4.1 > /usr/ports/lang/gcc45 <- 4.5.0 We may have to USE_GCC , at least for some earlier supported versions of the OS, if we want to retain some of the newer mplayer/mencoder features. (I was hoping to avoid this, but it may be the easiest way to solve some problems.) But remember that the entire toolchain is involved, not just the compiler -- our gcc ports are still wired by default to our system gnu binutils, as is our base system compiler. These older base system binutils lack support for some newer instruction sets. obrien@ said some time ago that he planned to update them to the latest GPLv2 versions, but he didn't respond to my later questions about progress on this front, so I'm assuming that this will not happen soon, especially with the release engineering that is now going on. Now that we have a newer devel/binutils port, we may be able to work around this -- for example, you can see how one submitter is trying to incorporate SSE3 support in the old sources: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/137043 As for the missing C99 features in our math and C libraries, we may be able to compensate for them with compiler built-ins, but not all versions of gcc have the necessary functions, nor are they present for all architectures, because the built-ins weren't really intended to be full replacements for library functions, but only to provide optimized versions for some architectures. And some of them are unfinished or broken, even in the latest versions of gcc: http://gcc.gnu.org/c99status.html So there will probably still be some minor surgery that needs to be done. b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d873d5be0907270719o14febae4v1fb134fd7b4f81ab>