Menu

#11 Compile errors

1.0
open
nobody
None
2017-08-31
2016-12-17
Bat Guano
No

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)
^~

Discussion

  • David Ricart

    David Ricart - 2017-01-17

    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.

     
  • Bat Guano

    Bat Guano - 2017-07-20

    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.

     
  • shevy

    shevy - 2017-08-26

    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.

     
    • Bat Guano

      Bat Guano - 2017-08-29

      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

       
      • David Ricart

        David Ricart - 2017-08-29

        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.

         
  • Bat Guano

    Bat Guano - 2017-08-29

    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?

    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))
          ~~~~~~~~~~~~~~^~~~~~~
    
     

    Last edit: Bat Guano 2017-08-29
    • Bat Guano

      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
      • David Ricart

        David Ricart - 2017-08-30

        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
        • Bat Guano

          Bat Guano - 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:

          cat lib/porg-log/Makefile | grep CXXFLAGS
          CXXFLAGS = -g -O2
          MY_CXXFLAGS = -W -ansi -pedantic -Wall -fno-operator-names -std=c++11 -Wno-deprecated-declarations -Wno-nonnull-compare -Werror
          

          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
          • David Ricart

            David Ricart - 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
  • Bat Guano

    Bat Guano - 2017-08-31
    opt.cc: In constructor Porg::Opt::Opt(int, char**):
    opt.cc:208:22: error: this statement may fall through [-Werror=implicit-fallthrough=]
        case '?': die_help();
                  ~~~~~~~~^~
    opt.cc:212:4: note: here
        default: assert(0); break;
        ^~~~~~~
    

    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
    • David Ricart

      David Ricart - 2017-08-31

      I think a simple break after die_help() would do the job. There's no need to call assert(0), because die_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.

       
      • Bat Guano

        Bat Guano - 2017-08-31

        Compiles out of the box (:wq)

         
        • David Ricart

          David Ricart - 2017-08-31

          Great. Thanks for helping.

           

Log in to post a comment.