3 May
2012
3 May
'12
11:06 p.m.
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.