ExternalLibraries/PAPI does not build with gcc 4.8.1

Issue #1459 closed
Roland Haas created an issue

not sure if this depends on the gcc version, but I get the following error when trying to compile PAPI:

PAPI: Building...
pfmlib_common.c: In function 'pfmlib_parse_event_attr':
pfmlib_common.c:760:10: error: declaration of 'endptr' shadows a previous local [-Werror=shadow]
    char *endptr = NULL;
          ^
pfmlib_common.c:737:20: error: shadowed declaration is here [-Werror=shadow]
  char *s, *p, *q, *endptr;
                    ^
cc1: all warnings being treated as errors

I attache the full output of make.

Keyword: PAPI

Comments (11)

  1. Roland Haas reporter
    • removed comment

    Can be avoided by calling configure like this

    CFLAGS=-Wno-error-shadow configures ...
    

    which is however gcc specific I believe.

  2. Erik Schnetter
    • removed comment

    This seems like a genuine error in the source code -- did you check? If so, we would want to use a newer version, or apply a patch to correct this.

  3. Roland Haas reporter
    • removed comment

    It is a warning about shadowed variables and shadowing is in principle allowed in C so there needs not be an actual error. The only reason that the compilation aborts is that PAPI seems to use flags to turn warnings into errors (and presumably that gcc 4.8.1 contains more warnings in -Wall than 4.7 did). As far as I can tell there is no error. The code (schematically) looks like this:

    while(foo) {
      char * endptr;
      /* no use of endptr*/
      if(bar) {
        char *endptr;
        strtod(...,&endptr);
        assert(*endptr == 0);
      }
      /* no use of endptr */
      if(baz) {
        strtod(...,&endptr);
        assert(*endptr == 0);
      }
      /* no use of endptr */
    }
    

    so is correct code and contains no bug. I looked into it a bit more and more proposed solution is probably too radical. There are other warnings-turned-into-errors later on, in particular also one about const-casts in free()'s argument which I can never remove. Essentially what happens is that one has:

    struct blah {
      const char *uname;
    };
    void somefunc(struct blah* b) {
      free((void*)b->uname);
    }
    

    which triggers the warning since free takes a non-const argument (even though you cannot use the data pointed to by the pointer afterwards anyway).

    Setting CFLAGS seems to just overwrite the CFLAGS that configure would use. Does anyone know how to append to the CFLAGS that configure constructs? Something like and --additional-cflags option?

    I attach a patch to PAPI and its configure.sh that patches the affected source files (there are multiple other warnings that were turned into errors) during the configuration phase.

    I am not sure if newer versions of PAPI compile successfully with gcc 4.8.1 or not.

  4. Erik Schnetter
    • removed comment

    Does PAPI set the respective warning options, or do they come from Cactus? I assume that PAPI adds the -Werror option, but if Cactus uses -Wall, then only the combination fails, and the proper solution would be to omit the warning options from Cactus.

  5. Roland Haas reporter
    • removed comment

    A grep for Werror in Cactus/configs/sim/scratch/build/PAPI/papi-5.1.0 finds it in various places. However my own config-info turns on -Wshadow which then gives the error. So one solution is to filter out -Wshadow from Cactus' CFLAGS (or have users not use it together with PAPI). I attach a patch that removes the ones that I had set and the prevented a build. However even with no Cactus set flags it still failes to build

    command_line.c: In function 'main':
    command_line.c:132:5: warning: 'data_type' may be used uninitialized in this function [-Wmaybe-uninitialized]
         switch (data_type) {
    
  6. Erik Schnetter
    • removed comment

    I like this patch.

    However, if this still fails to build, then we also need to remove -Werror from the options. It is customary to use -Werror while developing, but to disable it in the release, for just the reason we encounter here. Removing -Werror could be done via a patch to configure or in some other way.

  7. Roland Haas reporter
    • removed comment

    Before/just after we include PAPI in the ET list, this should be taken care of.

  8. Log in to comment