All,
I have opened a bug for handling gcc 4.7 build failure issues:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=958
I have also uploaded a complete set of build logs for the packages listed as not building due to gcc 4.7 changes. I have set the priority to 'major'. Tim will need to determine if this is what it should be or whether it should be elevated for R14. Thankfully the packages that are affected is relatively small. Thus far:
basket gwenview k3b kima kipi-plugins krusader python-tqt rosegarden tdebase ( now requires -fpermissive ) tdegames tdegraphics tdepim tdesdk
The big issue is that distros that ship or update to 4.7 will not be able to build TDE until these issues are resolved. That eliminates Archlinux as the build environment updates to build on the current stable release of all packages (including gcc).
Some build failures may be able to be handled by compiler/linker flags, where code changes will be required for the rest. The primary culprit seems to be gcc 4.7 implementation of additional features and extensions from C11 and C++11. The changes are summarized at: http://gcc.gnu.org/gcc-4.7/changes.html
My guess for the lead suspect is:
G++ now correctly implements the two-phase lookup rules such that an unqualified name used in a template must have an appropriate declaration found either in scope at the point of definition of the template or by argument-dependent lookup at the point of instantiation. As a result, code that relies on a second unqualified lookup at the point of instantiation to find functions declared after the template or in dependent bases will be rejected. The compiler will suggest ways to fix affected code, and using the -fpermissive compiler flag will allow the code to compile with a warning.
template <class T> void f() { g(T()); } // error, g(int) not found by argument-dependent lookup void g(int) { } // fix by moving this declaration before the declaration of f
template <class T> struct A: T { // error, B::g(B) not found by argument-dependent lookup void f() { g(T()); } // fix by using this->g or A::g };
struct B { void g(B); };
int main() { f<int>(); A<B>().f(); }
That would explain my need to use -fpermissive to build tdebase last night where I never needed it before.
Oh, well, the challenges of progress... Let's rip this apart and 'get her fixed' :)
On 04/05/2012 01:51 PM, David C. Rankin wrote:
All,
I have opened a bug for handling gcc 4.7 build failure issues:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=958
patch submitted that allows tdebase to build without -fpermissive. Thanks dev/ammo42 :)
http://bugs.pearsoncomputing.net/bugzilla/attachment.cgi?id=519
patch submitted that allows tdebase to build without -fpermissive. Thanks dev/ammo42 :)
http://bugs.pearsoncomputing.net/bugzilla/attachment.cgi?id=519
Will the patch hurt or confuse the build with pre gcc 4.7 systems?
Darrell
On 04/05/2012 07:10 PM, Darrell Anderson wrote:
Will the patch hurt or confuse the build with pre gcc 4.7 systems?
Darrell
I have no Freaking idea :)
It depends - presumably it should make a difference since it simply adds the
'this->' designation to the calls inside the template stuff, but I no 'nada' about the template library, etc... If I had something other than Arch, I'd give it a go. (I have suse, but I don't write .spec files :)
Maybe I should install Slack 13.37 and give that a spin.
I don't think it will hurt the earlier builds, since it just satisfies the compiler checks. Here is the patch:
--- kicker/applets/launcher/easyvector.h +++ kicker/applets/launcher/easyvector.h 2012-04-05 17:33:50.320708865 -0500 @@ -87,7 +87,7 @@ template < class VALUE, bool CHECKINDEX > void EasyVector< VALUE, CHECKINDEX >::eraseAt(Index index) { _checkIndex(index); - erase(this->begin()+index); + this->erase(this->begin()+index); }
@@ -108,7 +108,7 @@ this->push_back(value); return; } - insert(this->begin()+index,value); + this->insert(this->begin()+index,value); }
@@ -116,7 +116,7 @@ void EasyVector< VALUE, CHECKINDEX >::insertAt(EasyVector< VALUE, CHECKINDEX
::Index index,const EasyVector< VALUE, CHECKINDEX > &v)
{ index=_convertInsertIndex(index); _checkInsertIndex(index); - insert(this->begin()+index,v.begin(),v.end()); + this->insert(this->begin()+index,v.begin(),v.end()); }
It depends - presumably it should make a difference
since it simply adds the
fat-fingers : 'should not' make a difference...
I can test here (gcc 4.4.4). If there are no build failures I still need a way to test functionality before pushing the patch to GIT. How would that section of code be tested after installation?
Otherwise we need preprocessor conditions in the patch when to merge the changes.
Darrell
On Thu, 5 Apr 2012 17:31:59 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
It depends - presumably it should make a difference
since it simply adds the
fat-fingers : 'should not' make a difference...
I can test here (gcc 4.4.4). If there are no build failures I still need a way to test functionality before pushing the patch to GIT. How would that section of code be tested after installation?
There is zero semantic change, it is only a matter of anal C++ standards compliance.
Otherwise we need preprocessor conditions in the patch when to merge the changes.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I can test here (gcc 4.4.4). If there are no build
failures I still need a way to test functionality before pushing the patch to GIT. How would that section of code be tested after installation?
There is zero semantic change, it is only a matter of anal C++ standards compliance.
I just finished building tdebase with the patch on Slackware 13.1 (gcc 4.4.4). No build failures.
How do I test functionality. What does easyvector do?
I'll push to GIT if somebody provides a "signoff" approval.
Darrell
On Thu, 5 Apr 2012 18:27:04 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I can test here (gcc 4.4.4). If there are no build
failures I still need a way to test functionality before pushing the patch to GIT. How would that section of code be tested after installation?
There is zero semantic change, it is only a matter of anal C++ standards compliance.
I just finished building tdebase with the patch on Slackware 13.1 (gcc 4.4.4). No build failures.
How do I test functionality. What does easyvector do?
It mostly implements bounds-checking on top of C++ STL vectors. g++ actually already knew what to do with the source code (since it was suggested in the error messages David posted), it just didn't fix it automatically since the former code is not valid C++98.
I'll push to GIT if somebody provides a "signoff" approval.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 04/05/2012 08:27 PM, Darrell Anderson wrote:
I just finished building tdebase with the patch on Slackware 13.1 (gcc 4.4.4). No build failures.
How do I test functionality. What does easyvector do?
I'll push to GIT if somebody provides a "signoff" approval.
Darrell
add quixklaunch to the taskbar and add apps - I think...
On Thu, 5 Apr 2012 17:10:45 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
patch submitted that allows tdebase to build without -fpermissive. Thanks dev/ammo42 :)
http://bugs.pearsoncomputing.net/bugzilla/attachment.cgi?id=519
Will the patch hurt or confuse the build with pre gcc 4.7 systems?
Probably not, if you look at the underlying code there are already many this-> accesses. And anyway, slackware-current already has gcc-4.7 ;)
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Will the patch hurt or confuse the build with pre gcc
4.7 systems? Probably not, if you look at the underlying code there are already many this-> accesses. And anyway, slackware-current already has gcc-4.7 ;)
Yes, I should have remembered you are using Slackware. Are you using Current?
I'm using 13.1 and in no hurry to bump. I don't anticipate playing with Trinity on Current for a while yet, probably this summer after R14 is released, unless a slew of bug fixes are resolved real fast to provide me more time. Even then I likely will not move from 13.1 to 13.37. Likely I'll skip 13.37 and move from 13.1 to newest release. Of course, at the rate Patrick is moving with Current, that might be next year. :)
Darrell
On Thu, 5 Apr 2012 18:20:02 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
Will the patch hurt or confuse the build with pre gcc
4.7 systems? Probably not, if you look at the underlying code there are already many this-> accesses. And anyway, slackware-current already has gcc-4.7 ;)
Yes, I should have remembered you are using Slackware. Are you using Current?
No, but I read the logs ;)
I'm using 13.1 and in no hurry to bump. I don't anticipate playing with Trinity on Current for a while yet, probably this summer after R14 is released, unless a slew of bug fixes are resolved real fast to provide me more time. Even then I likely will not move from 13.1 to 13.37. Likely I'll skip 13.37 and move from 13.1 to newest release. Of course, at the rate Patrick is moving with Current, that might be next year. :)
Currently I also use 13.1 as the 13.37 Intel video drivers really suck on my machine. Actually I should make a chroot of it (and run -current or Arch) but I'm too lazy to do it ;)
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 04/05/2012 10:01 PM, /dev/ammo42 wrote:
Currently I also use 13.1 as the 13.37 Intel video drivers really suck on my machine. Actually I should make a chroot of it (and run -current or Arch) but I'm too lazy to do it ;)
Why be lazy, 10 minute arch install, then just run it:
http://www.3111skyline.com/dl/dt/tde/scr/mkNewArchChroot.sh
(as root of course...)
On 04/05/2012 01:51 PM, David C. Rankin wrote:
All,
I have opened a bug for handling gcc 4.7 build failure issues:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=958
I have updated the bug report with all information and patches that I have. There are still major packages that do not build and that I cannot fix. I have summarized the packages and errors in the bug report.
Tim, take a look and see if you want to elevate this bug to BLOCKER. As it sits, until we solve the issues, gcc47 distros will have no tdepim, k3b, or kipi-plugins.
Additionally, the following require '-fpermissive' to build with gcc47:
tdegraphics krusader amarok kaffeine tdeadmin tdegames tdeedu python-tqt
Digikam could not be tested against gcc47 due to still requiring libpng15 fix. See: http://bugs.pearsoncomputing.net/show_bug.cgi?id=949
However, the list of packages that build against gcc47 far outweighs those that don't. For current list for those packages building on arch, see:
http://www.3111skyline.com/dl/dt/tde/err/gcc47/gcc47-building.txt
-
/dev/ammo42 -
Darrell Anderson -
David C. Rankin