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...

-- 
David C. Rankin, J.D.,P.E.