FreeBSD Port: mplayer-0.99.11_14

[b. f.]

I think we'll investigate VLC as an alternative.  Not too comfortable
building around a solution that's not being maintained as it should be.

mplayer is definitely continuously developed, it's not an abandoned
project! They just do not follow a release scheme at the moment.

He may have been referring to the FreeBSD port here, not upstream. ;)

If the svn version does the job you want it to do, it's definitely worth a try.
I personally like mplayer as it is still lighter than VLC.

I was going to submit a snapshot update some months ago to Riggs, but
I got bogged down (sorry, Riggs!) with sound problems on my computer,
and other demands on my time. By the time that I returned to it,
upstream developers who were using Linux had introduced several
additional hurdles by using SSE3 and several C99 math functions that
were missing from our gcc 4.2 base compiler toolchain and our aging
and largely unmaintained math library. Since then, after complaints
from users on the mplayer mailing list who were attempting to build
snapshots on FreeBSD, they resolved some but not all of these problems
by just disabling some of the newer code, which is ... not altogether
satisfactory. Also, there was, the last time I checked, some kind of
problem with our base compiler on amd64. Suggested workarounds for
some of these problems were submitted by "Tomek" on March 2 to the
freebsd-multimedia mailing list (under messages entitled "x264 patch"
and "ffmpeg patch", but there are still some problems to resolve. So
this will probably require a little time and effort to update. If no
one else does it, I'll try to get to it in the next few weeks. It
definitely ought to be done.

b.

[Andriy Gapon]

Post by b. f.

I think we'll investigate VLC as an alternative. Not too comfortable
building around a solution that's not being maintained as it should be.

mplayer is definitely continuously developed, it's not an abandoned
project! They just do not follow a release scheme at the moment.

He may have been referring to the FreeBSD port here, not upstream. ;)

If the svn version does the job you want it to do, it's definitely worth a try.
I personally like mplayer as it is still lighter than VLC.

I was going to submit a snapshot update some months ago to Riggs, but
I got bogged down (sorry, Riggs!) with sound problems on my computer,
and other demands on my time. By the time that I returned to it,
upstream developers who were using Linux had introduced several
additional hurdles by using SSE3 and several C99 math functions that
were missing from our gcc 4.2 base compiler toolchain and our aging
and largely unmaintained math library. Since then, after complaints
from users on the mplayer mailing list who were attempting to build
snapshots on FreeBSD, they resolved some but not all of these problems
by just disabling some of the newer code, which is ... not altogether
satisfactory. Also, there was, the last time I checked, some kind of
problem with our base compiler on amd64. Suggested workarounds for
some of these problems were submitted by "Tomek" on March 2 to the
freebsd-multimedia mailing list (under messages entitled "x264 patch"
and "ffmpeg patch", but there are still some problems to resolve. So
this will probably require a little time and effort to update. If no
one else does it, I'll try to get to it in the next few weeks. It
definitely ought to be done.

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

[b. f.]

Post by Andriy Gapon
Just curious, can't newer GCC(s) from ports be used to build those mplayer snapshots?
/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.

[Mark Tinguely]

As a FYI and cross my fingers that this does not take an OT life of its own.

The newer ARM chips could benefit from a new GCC and GNU binutils. So
we have spent some time experimenting in this area.

I have added the FreeBSD kernel printing extensions (-fformat-extensions)
and the FreeBSD path (PREFIX) code and the freebsd config entries into the
GCC 4.5 (have kept it updated to the July snapshot). The GCC and libgcc have
been ported to BSD Makefiles, with the following exceptions:

1) I have not added the last two week changes to gcc/gcclibs.

2) for some reason gnu/usr.bin/cc/cc_tools/option.h must exist,
even if blank, before the compile begins. It must be a makefile
error.

3) In libdecnumber from GCC, I statically chose the dpd routines.

4) libgcc compiles with 8.0 header files. I believe there are errors
in the gcc libssp. If I remember, it was an error with an include file
that I got manually around.

5) libgmp/libmpfr required by the new compilers has not been ported,
right now I link them against /usr/local/lib. libgmp looks the
messiest of the two. In the mpn directory, there are generic routines
and per ARCH and sub-ARCH assembly replacements which require m4
preprocessing. Some replacements are for both add and subtract versions:
aors_n.asm is equivalent to add_n.asm and sub_n.asm.

For the ARM, I changed the hardware floating point to be "vfp".

I see there are ARCH restrictions of "NOT_FOR_ARCHS= alpha ia64 powerpc"
in the newer GCCs.

I have used the ported compiler mostly on the kernel sources. The standard
GCC 4.5 "-O" option kicks up several new warnings on the inline that
are conditional - a lot of them are inlines for locks.

I use the new binutils, but have not tried to port them to the BSD makefiles.

This is just a FYI of some of what would be require to update the native
compiler. I hate to think what port source issues would be.

--Mark Tinguely