This is not important
But just in case, an although I know that there are pending changes for some future release of porg awaiting finalization, maybe you should try to correct some minor coding problem as the svn-code fails to compile since the last update. I appear to be running a porg version from 19 June 2016, subversion reports Revision 184.
I am afraid, that the changes of 29 june have intrduced the problem, i.e. my own mentioning the missing version information... :-(
The current error is this :
In file included from basepkg.h:13:0,
from basepkg.cc:10:
common.h: In constructor ‘Porg::FileStream<T>::FileStream(const string&) [with T = std::basic_ifstream<char>]’:
common.h:43:4: error: nonnull argument ‘this’ compared to NULL [-Werror=nonnull-compare]
if (!this)
^~
common.h: In constructor ‘Porg::FileStream<T>::FileStream(const string&) [with T = std::basic_ofstream<char>]’:
common.h:43:4: error: nonnull argument ‘this’ compared to NULL [-Werror=nonnull-compare]
if (!this)
^~
Hi.
Thanks for the ticket.
The changes made in revision 184 were a "quick and dirty" way to fix the versioning issue that you reported in a previous ticket.
I have undone those changes in the current SVN trunk, because I'm not satisfied with them, and also because they may be the cause of the compilation problem that you report in this ticket.
So please, could you try to compile the current SVN version and tell us if you find the same compilation problem?
Also, I'll try to fix the versioning problem in future commits, when I'll find out how to do it.
Cheers,
~David.
I am sorry for the late response but have been (deliberately) without acces to the Internet for a while.
Today I have tried to compile the revision 186 and get new compile errors with g++ (Debian 6.4.0-1) 6.4.0 20170704:
In file included from basepkg.h:13:0,
from basepkg.cc:10:
common.h: In constructor ‘Porg::FileStream<T>::FileStream(const string&) [with T = std::basic_ifstream<char>]’:
common.h:43:4: error: nonnull argument ‘this’ compared to NULL [-Werror=nonnull-compare]
if (this == NULL)
^~
common.h: In constructor ‘Porg::FileStream<T>::FileStream(const string&) [with T = std::basic_ofstream<char>]’:
common.h:43:4: error: nonnull argument ‘this’ compared to NULL [-Werror=nonnull-compare]
if (this == NULL)
^~
I cannot claim to have followed the changes in the recent C++ standards or their implementation in compilers, but both, the comparison AND the error-message surprise me. You have your reasons, I am sure, but so has certainly g++. After a temporary deactivation of the error-handling, that the if-clause is meant for, I get the next one of the same kind:
log.c: In function ‘open’:
log.c:281:20: error: nonnull argument ‘path’ compared to NULL [-Werror=nonnull-compare]
if (!porg_tmpfile && path && !strncmp(path, "/proc/", 6))
~~~~~~~~~~~~~~^~~~~~~
log.c: In function ‘open64’:
log.c:385:20: error: nonnull argument ‘path’ compared to NULL [-Werror=nonnull-compare]
if (!porg_tmpfile && path && !strncmp(path, "/proc/", 6))
~~~~~~~~~~~~~~^~~~~~~
I may know nothing, and surely do. But both of these errors should be easily avoided. I would try replacing the if-clauses by a more direct handling of any situation that could render an object NULL in the first place... This still does not explain why g++ or who ... and why, really... I would not care.
Is this important? Beats me.
I was able to compile all of porg + the GUI part as well, which runs.
I have an up-to-date system though, gcc 7.2.0 and a somewhat ok glibc version.
Okay, then.
How can I deactivate the compiler option "-Werror=nonnull-compare" when running make?
gcc (Debian 7.2.0-1) 7.2.0
libc-2.24
Hi Bat.
Try setting the flag '-Wno-nonnull-compare' to the compiler at configure time. Like this:
CXXFLAGS='-Wno-nonnull-compare' ./configure --prefix=/usr
Also, I'll add it to the configure script, to make it permanent.
Thanks
I saw the ChangeLog before I saw the comment, above.
Alas, now it bails out at a different position, so the flag has certainly “done something”. The new error, however, is much less esoteric. Could it be of importance that there are 6 Makefiles in the trunk?
Last edit: Bat Guano 2017-08-29
The only way I was able to compile revision 187 was by replacing in all the Makefiles in the source-tree -Werror by -Wno-error. Trying to set flags outside the Makefile did apparently not affect each Makefile in the way I needed.
And I guess I understand now, why you choose to code if (!this). I have seen precompiler macros used in the same way and would not do it like that, myself. But I understand now.
Last edit: Bat Guano 2017-08-29
Did you run 'autoreconf' after updating to revision 187? It is needed to recreate the configure script.
The -Werror flag it's enabled only in the development version, to help me fix compilation warnings. But I think I would remove it completely, as it may be annoying to anyone else than me.
As of the
if (!this)
, I use it to check for successful creation of a fstream derived object, inside of its own constructor. If you know of a better way to achieve it, I'd be happy to know it.Thanks.
Last edit: David Ricart 2017-08-30
Thank you for keeping this up.
Even after make clean/distclean and autoreconf, then ./configure, compilation ends with the error when log.c is processed. The Makefile in porg-log contains, though:
I do not know... (,a lot of things, apparently and) if the order of individual values has an impact. How are CXXFLAGS read, anyway... and can we know?
Cheerio.
Last edit: Bat Guano 2017-08-30
OK.
log.c is compiled with gcc, not g++. So we have to add the '-Wno-nonnull-compare' flag to MY_CFLAGS as well.
Done in r188.
Last edit: David Ricart 2017-08-30
I just duplicated the “assert(0);break;” after the call to “die_help()”; I ignore, though, if and where you react to the failed assertion. An explicit fall through may be better or not...
Last edit: Bat Guano 2017-08-31
I think a simple
break
afterdie_help()
would do the job. There's no need to callassert(0)
, becausedie_help()
terminates the program anyway.Done in r189.
BTW: I do not react to failed assertions, because they're disabled on stable releases of porg. I just use them on development versions, to help detect errors.
Compiles out of the box (:wq)
Great. Thanks for helping.