Darrell,
Do you have the capability to build Kde3 on gcc 4.7 to test the kwrite issue. I don't know if you have the same capabilities to build KDE as you do TDE, but since I don't and since I haven't gotten a confirmation from the SuSE folks, I'm curious if building 3.5.10 will show the same crash. If you have the sources and build scripts for it, it is probably worth doing just to see if we can eliminate the tqtinterface code as a possible source. If it is the same crash in KDE as it is in TDE, then tqtinterface should be able to be eliminated.
Just a couple of stray thoughts that might add another piece of info to the puzzle. If it is tdelibs, then I'm not sure that it is even worth doing, but think about it.
Also, Tim, have you been able to set up a gcc 4.7 build environment yet? I know you have another 26,539 things to do, but the more eyes we get on this thing, the sooner we will find the culprit.
If anyone else has thought of another test they would like to see, then just let me know, happy to do it here -- as long as I know what to do. Thanks.
Do you have the capability to build Kde3 on gcc 4.7 to test the kwrite issue. I don't know if you have the same capabilities to build KDE as you do TDE, but since I don't and since I haven't gotten a confirmation from the SuSE folks, I'm curious if building 3.5.10 will show the same crash. If you have the sources and build scripts for it, it is probably worth doing just to see if we can eliminate the tqtinterface code as a possible source. If it is the same crash in KDE as it is in TDE, then tqtinterface should be able to be eliminated.
In short, I have the capability, but I haven't tinkered with building 3.5.10 for a long time. Primary challenge is mental cobwebs. :-) Second, although I have a collection of most of the 3.5.10 patches needed, I don't have all and I don't have any of the 4.7 patches backported --- and stripped of the TQt layer.
Do you know where the OpenSuse folks keep their 3.5.10 patches collection?
I'm still pretty busy of late with non Trinity things. I won't commit to testing 3.5.10, but I won't say no either. Starting the process is easy enough but every time a package fails to build I have to analyze what I need to correct the failure. Basically, hunt for the appropriate patch. Yet building the core packages, which is all that is needed to test the problem, probably is going to be time consuming. I likely would be able to get there eventually, but I am not in a position time wise or patch wise to "merely" run a build sequence.
Thus far, the GCC 4.7 issues basically kills using Trinity on the latest Arch. Everybody else still has breathing room. Although Tim hasn't said anything, I suspect we won't release R14.0.0 without finding a solution. Further, we shouldn't release R14.0.0 without those patches because shortly thereafter other distros will be moving to GCC 4.7. Without a fix now, we would be forced into releasing R15 or R14.1.0. Better to fix the problem in R14.0.0 now to provide us breathing room in the upcoming months.
Besides, we have two or three dozen usability bugs that should be fixed before releasing R14, not to mention a few dozen build issues (although many of the build issues are similar --- patch one and patch the similar ones very quickly thereafter). In other words, I suspect we'll resolve the GCC 4.7 problems sooner or later.
I notice Tim has started poking his head into the bug tracker. Hopefully all of this starts gelling together Real Soon Now. :-)
Darrell
Do you have the capability to build Kde3 on gcc 4.7 to test the kwrite issue. I don't know if you have the same capabilities to build KDE as you do TDE, but since I don't and since I haven't gotten a confirmation from the SuSE folks, I'm curious if building 3.5.10 will show the same crash. If you have the sources and build scripts for it, it is probably worth doing just to see if we can eliminate the tqtinterface code as a possible source. If it is the same crash in KDE as it is in TDE, then tqtinterface should be able to be eliminated.
In short, I have the capability, but I haven't tinkered with building 3.5.10 for a long time. Primary challenge is mental cobwebs. :-) Second, although I have a collection of most of the 3.5.10 patches needed, I don't have all and I don't have any of the 4.7 patches backported --- and stripped of the TQt layer.
Honestly I really wouldn't bother. Even if 3.5.10 builds and works, it won't help TDE one bit in fixing the problem. <snip>
Although Tim hasn't said anything, I suspect we won't release R14.0.0 without finding a solution. Further, we shouldn't release R14.0.0 without those patches because shortly thereafter other distros will be moving to GCC 4.7. Without a fix now, we would be forced into releasing R15 or R14.1.0. Better to fix the problem in R14.0.0 now to provide us breathing room in the upcoming months.
Here's my official statement: R14.0.0 will NOT be released until it builds and functions under gcc 4.7.
Tim
In short, I have the capability, but I haven't tinkered with building 3.5.10 for a long time. Primary challenge is mental cobwebs. :-) Second, although I have a collection of most of the 3.5.10 patches needed, I don't have all and I don't have any of the 4.7 patches backported --- and stripped of the TQt layer.
Honestly I really wouldn't bother. Even if 3.5.10 builds and works, it won't help TDE one bit in fixing the problem.
Yeah, that too. :-) Although I have a basic shell script to perform TQt stripping, which I use to help me identify differences from 3.5.10 for debugging purposes, the script is not robust or 100% dependable. Further, if 3.5.10 did build correctly, that would not necessarily identify the TQt layer as the culprit. :-(
Here's my official statement: R14.0.0 will NOT be released until it builds and functions under gcc 4.7.
Enough said. :-)
Darrell
-
Darrell Anderson -
David C. Rankin -
Timothy Pearson