Evan Martin (evan) wrote in evan_tech,
Evan Martin

mplayer altivec, osx vs ppc-linux

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...

  • blog moved

    As described elsewhere, I've quit LiveJournal. If you're interested in my continuing posts, you should look at one of these (each contains feed…

  • dremel

    They published a paper on Dremel, my favorite previously-unpublished tool from the Google toolchest. Greg Linden discusses it: "[...] it is capable…

  • treemaps

    I finally wrote up my recent adventures in treemapping, complete with nifty clickable visualizations.

  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.