10 Apr
2012
10 Apr
'12
6:11 p.m.
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().
--
David C. Rankin, J.D.,P.E.
10 Apr
10 Apr
6:27 p.m.
New subject: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??
On Tue, 10 Apr 2012 13:11:20 -0500
"David C. Rankin" <drankinatty(a)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().
11:35 p.m.
New subject: Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
On 04/10/2012 01:27 PM, /dev/ammo42 wrote:
On Tue, 10 Apr 2012 13:11:20 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
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
--
David C. Rankin, J.D.,P.E.
All,
From 'man getuid':
#include <unistd.h>
#include <sys/types.h> 
11:40 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
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 
11:44 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
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
11:48 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
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 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
11 Apr
11 Apr
1:07 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
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 :-)
--
David C. Rankin, J.D.,P.E.
2:18 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
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
2:48 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
On Wed, 11 Apr 2012 07:18:38 -0700 (PDT)
Darrell Anderson <humanreadable(a)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.
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
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)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
3:02 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
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
3:37 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
On Wed, 11 Apr 2012 08:02:07 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> 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.
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
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)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
4:27 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
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.
--
David C. Rankin, J.D.,P.E.
4:31 p.m.
New subject: [trinity-devel] Please push - basket gcc47 patch [was Re: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??]
On 04/11/2012 12:27 PM, David C. Rankin wrote:
On 04/11/2012 10:37 AM, /dev/ammo42 wrote:
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!
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.
10 Apr
10 Apr
6:31 p.m.
New subject: [trinity-devel] basket notepad failure (oh no!) - 'getuid' was not declared in this scope ??
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....
--
David C. Rankin, J.D.,P.E.
4657
days inactive
4658
days old
13 comments
5 participants
participants (5)
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Timothy Pearson