Quite often, thanks to the ranks of tweaks and hacks that many people on the Internet post, you can get a bit of software to work better, faster, or whatever. However from time to time, it just totally fails.
I’ve had the experience with the optimised Firefox builds that are regularly posted by Neil Lee. I’ve been using these for a while, as they are compiled for specific processors, and as such are generally faster than the regular Mac version of Firefox. As Neil says on his site all he’s doing is just recompiling the existing Firefox build, which made my odd problem with the new version all the more strange.
A look at the release notes for the latest version, 1.5.0.1 show that this is a pretty minor bug fix release, and the official release looks and runs exactly the same as before. However the same can’t be said for the optimised build, which has a fundamental problem with the Bloglines site – a bit of a problem as that is one of the major sites I use to track over 100 different blogs and feeds. The problem is that the new build doesn’t function correctly with the frame based feeds page – whereas the standard build quite happily allows you to click a feed in the left hand frame and shows you the latest updates on the right, the optimised build doesn’t do this – instead it generates a new, blank tab, and never shows you the feed.
Anyway, I’m sure if it’s a pretty common problem it will be sorted out quite quickly, but until then I’m back to the slow old standard release – not that it doesn’t work, it’s just a bit like the difference between the courtesy car you get when your car is in being repaired, and the car you’re used to!
Well, a compiler is allowed to take many shortcuts in C and C++ when optimising code. Sometimes the author of a piece of code unintentionally relies on the particular results of undefined behaviour on a given compiler, or when that compiler has particular optimisation options enabled. I recall some code I had to debug at work which worked fine in a debug build, but not in release mode. It turned out that the code relied on the value of a boolean expression being either 0 or 1, but the C specification only guarantees that the result will be zero or non-zero. The code generated in debug mode always produced a 1 for a true result, but the release version reused one of the inputs and could therefore be any non-zero value.
This is what concerns me about the concept of source, rather than binary, distribution, and asking the end-user to compile it themselves. Unless the compiler is the exact version that the developer used, and the same options are used to compile it, the resulting binary could be different. We always test the actual binary, or combination of binaries, that will be shipped.