trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: May 2012

Re: [trinity-devel] Build KDE3 on gcc 4.7 to test kwrite issue?

From: Darrell Anderson <humanreadable@...>
Date: Mon, 14 May 2012 11:43:49 -0700 (PDT)
>   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