You might have noticed that the FATE Server includes configurations for building the latest FFmpeg source using the latest SVN builds of the actual compiler, gcc. This was suggested by several people as a way to monitor how the development of such a crucial piece of software effects another crucial piece. But it has also led me to wonder how to keep the gcc-svn version reasonably up to date.
First idea: Pre-built binaries from another source. I know of nothing of the sort, presently.
Next idea: Periodically building the compiler myself. This has a lot of issues, not the least of which is the fact that on both of the current build machines, the compiler takes at least 4 hours to build. And that’s with just ‘–enable-languages=c’, and without any FATE build/test cycles occurring.
Solution: Offload the periodic gcc builds to another machine. I can build the C compiler in just under an hour on a multi-core x86_32 Linux machine, rather than the single-CPU VMware session that currently serves x86_32 build duty on the FATE farm. I have another PowerPC that should also be able to take over building the PPC compiler.
So the next problem becomes: how often to update the gcc SVN compiler in use? Every day? Every 2 days? Every week? I don’t have a good answer for this, but it leads to the next question…
How to keep track of these new gcc SVN builds? Should there be a new configuration for each new SVN build? (A configuration in FATE parlance is a combination of a machine and a compiler version.) Or should I update one master configuration with the latest compiler path and name information (moving from gcc-svnABC-date1 to gcc-svnXYZ-date2)? The former solution would be more pure but the latter might yield superior performance data over an extended period of time. At least, it will once I get more tests into the system, which should happen soon.
Add –disable-bootstrap to the build and it’ll be at least 2x faster.
I’m pretty sure updating it from the current SVN will fix all those “array subscript is above array bounds” warnings, by the way.
I can’t think of a really good reason to keep old SVN revisions around.
Thanks for the tip. However, –disable-bootstrap didn’t make a difference. In fact, the build time was slightly longer, albeit negligibly. This is for x86_32.
Well, that’s weird. –disable-bootstrap just turns off the part where the compiler rebuilds itself again. Did you do it on a clean build?
I always do fresh, out-of-tree builds when I do this (I always like to take the builds with a different path name that includes the SVN level and build date).
I actually just did a full rebuild on the PPC side with –disable-bootstrap and, quite surprisingly, it finished in 40 minutes.
Are you building gcc with support for just the languages you need? (“–enable-languages=c,c++,…”)
Yep, and even fewer than in your example. I am just enabling C since that’s all that FFmpeg really needs.
I mean, until we re-write the whole thing in Java, which I’m told is inevitable.
Well debian unstable ships gcc-snapshot, perhaps that could help?
If I were running Debian, perhaps. The x86_32 VMware image is Ubuntu-based, and I’m not sure if gcc-snapshot is available. The PPC box is still Gentoo-based.
@astrange: I just upgraded the PPC gcc-SVN version and the latest builds still report “array subscript is above array bounds†warnings are still present. Just FYI, not blaming you or anything. :-)
Well, at least one of those warnings is an actual bug:
/tmp/fate/source/libavutil/aes.c:133: warning: array subscript is above array bounds
In aes.c:133:
if(!enc_multbl[0][sizeof(enc_multbl)/sizeof(enc_multbl[0][0])-1]){
I take it this was meant:
if(!enc_multbl[0][sizeof(enc_multbl[0])/sizeof(enc_multbl[0][0])-1]){
Thanks, SvdB. I’ve forwarded your comment to the dev list for consideration.
Didnt know about the automated test environment. Thanks for this post. Also I am wondering at what stage the rewrite of ffmpeg in java as hinted to by multimedia mike is at?
It turns out that it was not a bug… ironically I now have less confidence in this code as a result.