shebs raised a good point, that a static dump_syms binary in CVS may not work properly on all systems. While this shouldn't be an issue for official builds, since we have a defined reference platform, we should put in a configure check to make sure that the dump_syms tool 1) runs and 2) produces correct output. If it doesn't work, we can disable the buildsymbols target. We may also want to provide an option to specify a self-built dump_syms in that case.

On windows we checked in a binary because building dump_syms required extra SDK headers, correct? I wouldn't expect that to be necessary on other systems, and recommend that we compile it by default on other systems. Is that not practical?

On Linux, it requires OpenSSL, which is going to be a new build dependency. I don't know about Mac. The other option would be to check for any additional dependencies, and just disable building dump_syms if they're missing.

I also had to make a VC71 version for us... If you don't have VC8 installed then the dump_syms tool won't operate correctly.

Building from source has its good and bad points - for instance, means that you have to maintain a local copy of the code even though there's only about 2-3 people in the whole world that will actually have a use for the dump_syms part. Adds to checkout/configure/build times, etc. When I fiddle with these a bit more, I'll have a better idea of any other issues that there might be, like system framework dependencies for Mac.

I had forgotten about bent's problem, and that does suck. I still think that given the limited target audience of the breakpad stuff, it will be sufficient to have executables checked in, and a configure test to test that they function properly. Another configure option to specify a self-built dump_syms would allow a way forward for problematic configurations.

I'm going to switch this to cover Win32, I guess. On OS X, we seem to be able to build the tool just fine with standard system libraries. I still have to deal with Linux, but a pre-built binary there is probably a bad idea anyway. What I'd like to do is keep the pre-built binary in the tree for Win32, but do a configure test to see if the user is capable of compiling their own, and if so, do that instead.

This got fixed in bug 623183. Leave it to me to file a dupe of my own bug and then not notice that it got fixed.