Previous Entry Share Next Entry
Frustrated by mplayer failing to play another movie, I noticed I'd built my binary in mid-2002. Time for a new one!

Unfortunately, it failed to build. The only reference to the problem Google found was on LJ, too.

It turns out that the problem is that the altivec code for mplayer was written on OS X and not Linux, and apparently the compilers (which are both gcc, as far as I knew?) have implemented the altivec vectors differently.
This patch fixes it, and it's worth glancing at to see the difference. The syntax for the vector type appears to be vector [size] where "size" is a type (like unsigned char), but the OS X gcc initializes it with weird (value,value,value,...) syntax instead Linux-gcc's {value,value,value,...} (analagously to struct and array initializers).

Once you're pulling in the altivec header, there's a conflict with /usr/include/sys/uio.h, which names a variable in a prototype __vector. Yikes. At least it's harmless to change a prototype. (This is possibly my fault, as I dinked around in the source a bit until I found the patch.)

That, plus a few other hacks (bad include paths, etc.) means I can now play my movies.
(In retrospect, I probably should've started with the CVS mplayer and gone from there.)

Obligatory O'Caml note: they use separate namespaces for types and variables, so code like this is legal:
# type x = A | B;;
type x = A | B
# let x = A;;
val x : x = A

Here, I have a binding "x" with type "x". There's an interesting parsing interaction going on with the way C declares variables, with syntax of simply type identifier;, that I haven't fully thought out yet. (It's impossible to have that in a language that does function application without parenthesis, which is I think why ML and Haskell have gone the identifier :: type approach instead.)

Of course, an entirely different question is whether having variables and types with the same name is a good idea...