On 05/03/2012 05:55 PM, Nix wrote:
Localizing the fault, I'd say. Since GCC 4.6 and 4.7 share the same C++ ABI (unless explicitly instructed otherwise, and if not compiling for C++11), you can binary-search for the faulty file by picking a random half of the files (or directories) and compiling *only them* with GCC 4.7, and compiling the other half with GCC 4.6. If it doesn't crash, flip the halves: otherwise, halve that half and compile one half with 4.6 and one half with 4.7, and iterate until you have only one file left. With only one file left you have a reasonable amount of code to start dissecting by hand for further info.
This is, I know, really really really boring. But it should work. :)
That makes sense. I have kicked off a gcc47 build with todays GIT tree that will complete later this evening. If I'm still up, I'll start another build with gcc46. Then we will have a gcc46 and gcc47 set of files. I guess we would then want to install the gcc46 files and then incrementally install/test/remove the gcc47 files until we find the file that causes the failure. Once built, it shouldn't be that bad since there are only 3 prime candidates -- tqt3, tdelibs, tdebase.
Boring? I like watching paint dry...