ffmpeg-0.4.9-pre1

[Dennis Veatch]

Until the bump to gcc-3.4.4 and glibc-2.3.5 ffmpeg has always compiled fine 
for me. Since this bump it has not. I get an Error 1 on the libavcodec.so, 
undefined references to wm0101, wm1010, wm1100 and magicF2W and the build 
fails. Now I normally run -O2, MMX, SSE, x387 and SSE and a wide range of 2.6 
kernels, this has always worked.

During my playing around with this (without the -fno-unit-at-a-time) I have 
found the fall down point to be the base speed optimization. Trying it 
without any of the extentions and floating point stuff still failed at O2.

So dropping O2 to O1 and it worked. To see how far I could go at that base 
level. I then added every cpu extention and floating point stuff my processor 
supports. It still compiled successfully. So the culprit, as far as I can 
determine is the base speed.

Googling around gets a number of hits about this and the proposed fix (I 
assume temporary) is to add "-fno-unit-at-a-time". I tried this and it did 
work but increases the compile time by about 2-3. I'm not particularly fond 
of that suggestion.

OTOH while perusing ffmpegs website (such that it is). I see they recommend 
ffmpeg's use be derived from their cvs instead of the "official releases". I 
know it's not standard practice to put cvs apps as a standard in moonbase. 
But I wonder if some consideration be given in this case.

I have created a module to try their cvs version with my normal optimizations 
and it works just fine. It also works fine with some additional optional 
depends the normal ffmpeg build does not have.

So I guess there are four things to concider here.

1. Tell those who have this problem to drop their base optimizations speed to 
O1. Which of course is the easiest thing to do.

2. Change the default ffmpeg module to the cvs version.

3. Add the cvs module I created to moonbase/zbeta.

4. Add the "-fno-unit-at-a-time" to the BUILD.

We I think the pretty well covers it. I would be interested to hear your 
thoughts on this.