All,
This is my goto app that was building fine, now I get a "'getuid' was not declared in this scope" error? What is that? Full error:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -D_LARGE_FILES=1 -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT password.lo -MD -MP -MF .deps/password.Tpo -c password.cpp -fPIC -DPIC -o .libs/password.o kicondialog.cpp: In member function 'const TQString& KIconButton::customLocation() const': kicondialog.cpp:509:61: warning: returning reference to temporary [enabled by default] likeback.cpp: In member function 'void LikeBack::fetchUserEmail()': likeback.cpp:618:23: error: 'getuid' was not declared in this scope mv -f .deps/kiconcanvas.Tpo .deps/kiconcanvas.Plo /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -D_LARGE_FILES=1 -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT colorpicker.lo -MD -MP -MF .deps/colorpicker.Tpo -c -o colorpicker.lo colorpicker.cpp make[2]: *** [likeback.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -D_LARGE_FILES=1 -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT colorpicker.lo -MD -MP -MF .deps/colorpicker.Tpo -c colorpicker.cpp -fPIC -DPIC -o .libs/colorpicker.o mv -f .deps/kicondialog.Tpo .deps/kicondialog.Plo mv -f .deps/password.Tpo .deps/password.Plo mv -f .deps/colorpicker.Tpo .deps/colorpicker.Plo make[2]: Leaving directory `/build/src/basket/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/basket' make: *** [all] Error 2 ==> ERROR: A failure occurred in build().
On Tue, 10 Apr 2012 13:11:20 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
All,
From 'man getuid': #include <unistd.h> #include <sys/types.h>
This is my goto app that was building fine, now I get a "'getuid' was not declared in this scope" error? What is that? Full error:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -D_LARGE_FILES=1 -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT password.lo -MD -MP -MF .deps/password.Tpo -c password.cpp -fPIC -DPIC -o .libs/password.o kicondialog.cpp: In member function 'const TQString& KIconButton::customLocation() const': kicondialog.cpp:509:61: warning: returning reference to temporary [enabled by default] likeback.cpp: In member function 'void LikeBack::fetchUserEmail()': likeback.cpp:618:23: error: 'getuid' was not declared in this scope mv -f .deps/kiconcanvas.Tpo .deps/kiconcanvas.Plo /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -D_LARGE_FILES=1 -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT colorpicker.lo -MD -MP -MF .deps/colorpicker.Tpo -c -o colorpicker.lo colorpicker.cpp make[2]: *** [likeback.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -D_LARGE_FILES=1 -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT colorpicker.lo -MD -MP -MF .deps/colorpicker.Tpo -c colorpicker.cpp -fPIC -DPIC -o .libs/colorpicker.o mv -f .deps/kicondialog.Tpo .deps/kicondialog.Plo mv -f .deps/password.Tpo .deps/password.Plo mv -f .deps/colorpicker.Tpo .deps/colorpicker.Plo make[2]: Leaving directory `/build/src/basket/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/basket' make: *** [all] Error 2 ==> ERROR: A failure occurred in build().
On 04/10/2012 01:27 PM, /dev/ammo42 wrote:
On Tue, 10 Apr 2012 13:11:20 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
All,
From 'man getuid': #include <unistd.h> #include <sys/types.h>
Thank you my friend! Fixed in PKGBUILD with:
cd ${srcdir} sed -i '/#include <kdebug.h>/s|$|\n#include <unistd.h>\n#include <sys/types.h>|' ${pkgname//tde-}/src/likeback.cpp
Darrell, please verify this patch and have it pushed.
md5sum: 3e7350c530d1324d1b4afbdcbe21fee0
From 'man getuid': #include <unistd.h> #include <sys/types.h>
Thank you my friend! Fixed in PKGBUILD with:
cd ${srcdir} sed -i '/#include <kdebug.h>/s|$|\n#include <unistd.h>\n#include <sys/types.h>|' ${pkgname//tde-}/src/likeback.cpp
Darrell, please verify this patch and have it pushed.
md5sum: 3e7350c530d1324d1b4afbdcbe21fee0
I can push, but somebody first please confirm for me, the C++ noob, that adding a header in the preprocessor includes does not impact backwards compatibility. That is, adding that include will not cause build failures with a gcc previous to 4.7
Darrell
From 'man getuid': #include <unistd.h> #include <sys/types.h>
Thank you my friend! Fixed in PKGBUILD with:
cd ${srcdir} sed -i '/#include <kdebug.h>/s|$|\n#include <unistd.h>\n#include <sys/types.h>|' ${pkgname//tde-}/src/likeback.cpp
Darrell, please verify this patch and have it pushed.
md5sum: 3e7350c530d1324d1b4afbdcbe21fee0
I can push, but somebody first please confirm for me, the C++ noob, that adding a header in the preprocessor includes does not impact backwards compatibility. That is, adding that include will not cause build failures with a gcc previous to 4.7
Darrell
His patch is correct. It is (nearly) impossible to break compilation by including new base system headers that were included in previous gcc versions via include chaining.
I really wonder why gcc can't leave well enough alone sometimes...we can't be the only large project affected by this change...
Tim
I can push, but somebody first please confirm for me,
the C++ noob, that adding a header in the preprocessor includes does not impact backwards compatibility. That is, adding that include will not cause build failures with a gcc previous to 4.7
His patch is correct. It is (nearly) impossible to break compilation by including new base system headers that were included in previous gcc versions via include chaining.
I thought so, but wasn't sure. :)
I really wonder why gcc can't leave well enough alone sometimes...we can't be the only large project affected by this change...
Okay, add the gcc developers to the poopie list along with the libpng and libjpeg developers. Time for a blanket party?
Darrell
On 04/10/2012 06:44 PM, Timothy Pearson wrote:
I really wonder why gcc can't leave well enough alone sometimes...we can't be the only large project affected by this change...
It has become an annual tradition for gcc to break things this time of year. Recall roughly a year ago and gcc 4.5.2 which prompted running through the code to add '#include <cstddef.h>' throughout and redoing all the foo::foo(a) designations to foo(a)?
Generally the gcc changes are to provide for the future, unfortunately not giving that much weight to the past. No we are not the only large project affected, but we are hit especially hard due to the small manpower-to-codebase_size of this project. Where other large projects, k4, gnome, etc.. may have hundreds of developers to help with changes, we have a relative few.
Somehow -- it always gets done :-)
If there were more time/manpower available, we would have the luxury of comparing the current c++ coding standards to the current code as we work through the gcc 4.7 changes -- that would hopefully eliminate or lesson the 2013 rat-race when gcc 4.8 comes out :-)
Generally the gcc changes are to provide for the future, unfortunately not giving that much weight to the past. No we are not the only large project affected, but we are hit especially hard due to the small manpower-to-codebase_size of this project. Where other large projects, k4, gnome, etc.. may have hundreds of developers to help with changes, we have a relative few.
This the overwhelming attitude throughout free/libre software developers: screw backwards compatibility. Damn the torpedoes, full speed ahead with bleeding edge!
I understand the reasoning: much less overhead and tighter code. Yet idealism seldom satisfies reality. Backwards compatibility is necessary.
Darrell
On Wed, 11 Apr 2012 07:18:38 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
Generally the gcc changes are to provide for the future, unfortunately not giving that much weight to the past. No we are not the only large project affected, but we are hit especially hard due to the small manpower-to-codebase_size of this project. Where other large projects, k4, gnome, etc.. may have hundreds of developers to help with changes, we have a relative few.
This the overwhelming attitude throughout free/libre software developers: screw backwards compatibility. Damn the torpedoes, full speed ahead with bleeding edge!
I understand the reasoning: much less overhead and tighter code. Yet idealism seldom satisfies reality. Backwards compatibility is necessary.
But here g++ developers *do* provide backwards compatibility, it is called -fpermissive. And there is no "bleeding edge" at all unless you consider C++98 to be a bleeding edge standard. Anyway, old compilers still work. On my Slackware 13.1 system, I have g++-3.4 installed into /opt, and I can use it to compile a working program against system Qt4 thanks to system g++ being backwards compatible with g++-3.4 in terms of ABI.
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
But here g++ developers *do* provide backwards compatibility, it is called -fpermissive. And there is no "bleeding edge" at all unless you consider C++98 to be a bleeding edge standard. Anyway, old compilers still work. On my Slackware 13.1 system, I have g++-3.4 installed into /opt, and I can use it to compile a working program against system Qt4 thanks to system g++ being backwards compatible with g++-3.4 in terms of ABI.
Okay, I sit corrected. :) Yet I believe the overall general attitude among many free/libre developers remains correct. The libpng project seems like a good example. Every dot-zero release requires everybody else to scramble to fix code.
Darrell
On Wed, 11 Apr 2012 08:02:07 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
But here g++ developers *do* provide backwards compatibility, it is called -fpermissive. And there is no "bleeding edge" at all unless you consider C++98 to be a bleeding edge standard. Anyway, old compilers still work. On my Slackware 13.1 system, I have g++-3.4 installed into /opt, and I can use it to compile a working program against system Qt4 thanks to system g++ being backwards compatible with g++-3.4 in terms of ABI.
Okay, I sit corrected. :) Yet I believe the overall general attitude among many free/libre developers remains correct. The libpng project seems like a good example. Every dot-zero release requires everybody else to scramble to fix code.
Guns don't kill people, people kill people. Concerning libpng it's the same thing: libpng doesn't break compatibility, distributions break compatibility. For example, libpng 1.0 was evicted from Slackware at version 9.0 (March 2003) but is still in Fedora 16 (the latest). And libpng 1.0 is still maintained upstream BTW.
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/11/2012 10:37 AM, /dev/ammo42 wrote:
Guns don't kill people, people kill people. Concerning libpng it's the same thing: libpng doesn't break compatibility, distributions break compatibility. For example, libpng 1.0 was evicted from Slackware at version 9.0 (March 2003) but is still in Fedora 16 (the latest). And libpng 1.0 is still maintained upstream BTW.
Excellent example.
Especially libpng. I don't know why arch couldn't maintain a libpng12, libpng14 and libpng15. The maintenance of the older packages is 'zip' and would have continued to provide needed soname report for older programs without forcing a rebuild of everything that relied on libpng.
The downside to continue to provide the earlier versions is it provides no motivation for brining code current. "Why go to the trouble of updating code for libpng15 if you can just install an older libpng and move on?" Human nature shows there is little chance of motiving code updates in that circumstance.
So yes, there will be a bit of pain to update for gcc47, libpng15, etc..., but in the end, TDE is current, builds on current libs, is much less time consuming to maintain (incompatibility from old code always surfaces), and it make TDE that much more likely to be picked up, packaged and maintained by the distros as an alternative desktop.
It's a cup 1/2 empty or cup 1/2 full thing to me.
On 04/11/2012 12:27 PM, David C. Rankin wrote:
On 04/11/2012 10:37 AM, /dev/ammo42 wrote:
Guns don't kill people, people kill people. Concerning libpng it's the same thing: libpng doesn't break compatibility, distributions break compatibility. For example, libpng 1.0 was evicted from Slackware at version 9.0 (March 2003) but is still in Fedora 16 (the latest). And libpng 1.0 is still maintained upstream BTW.
Excellent example.
Especially libpng. I don't know why arch couldn't maintain a libpng12, libpng14 and libpng15. The maintenance of the older packages is 'zip' and would have continued to provide needed soname report for older programs without forcing a rebuild of everything that relied on libpng.
Because arch packagers only maintain what upstream provides. If you want older versions look in the AUR. This for me is a good reason to use Arch. when a program is released, a new version. I want it right away. I am not going to sit around for a year to get a new version. New versions mean improvements and fixes, and so a core library like libpng? you bet i want that new version, since large parts of my system relies on it!
The downside to continue to provide the earlier versions is it provides no motivation for brining code current. "Why go to the trouble of updating code for libpng15 if you can just install an older libpng and move on?" Human nature shows there is little chance of motiving code updates in that circumstance.
So yes, there will be a bit of pain to update for gcc47, libpng15, etc..., but in the end, TDE is current, builds on current libs, is much less time consuming to maintain (incompatibility from old code always surfaces), and it make TDE that much more likely to be picked up, packaged and maintained by the distros as an alternative desktop.
It's a cup 1/2 empty or cup 1/2 full thing to me.
On 04/10/2012 01:11 PM, David C. Rankin wrote:
error: 'getuid' was not declared in this scope
Looks like all the package failures will be gcc47. However, it looks like the fix will be fairly simple, but time consuming. Apparently, the errors occur because gcc 47 removed numerous "unnecessary" includes from the standard library headers.
You will now be required to #include <unistd.h> where you experience build failures of the type:
error: ‘access’ was not declared in this scope error: 'getuid' was not declared in this scope error: ‘sleep’ was not declared in this scope error: ‘usleep’ was not declared in this scope
and on and on and on....
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Timothy Pearson