[petsc-dev] [petsc-maint] valgrind detected on /usr/local/include and enabled but header files from this dir are not added to build path

[Barry Smith]

   Satish,

   After a git pull or something we often run 

   $PETSC_ARCH/conf/reconf*.py 

   but sometimes it pays to delete $PETSC_ARCH first, but then $PETSC_ARCH/conf/reconf*.py  doesn’t exist and then we have these absurdly cumbersome

   cp $PETSC_ARCH/conf/reconf*.py 
   rm -rf $PETSC_ARCH
   reconf*.py 
   rm reconf*.py 

   commands.

    Could you please add a —with-clean (or better name?) option to ./configure that does the $PETSC_ARCH removal business? Then we can just run

    $PETSC_ARCH/conf/reconf*.py  —with-clean

   Also make sure that the —with-clean option is NOT stored in the resulting $PETSC_ARCH/conf/reconf*.py  file so it doesn’t get continuously used after that.

   Then we can get rid of the whole silly “rm $PETSC_ARCH” business first,

    Thanks

     Barry



On Oct 29, 2013, at 6:22 AM, Aron Ahmadia <aron at ahmadia.net> wrote:

> Thanks, this fixed it.  Should I in principle always start in a 'clean' PETSC_ARCH after a rebuild? 

  
> 
> A
> 
> 
> On Tue, Oct 29, 2013 at 5:30 AM, Karl Rupp <rupp at mcs.anl.gov> wrote:
> Hey,
> 
> 
> > That said, 'master' isn't building for me due to the following error:
> 
>       CLINKER
> /Users/aron/sandbox/petsc/arch-darwin-c-debug/lib/libpetsc.dylib
> Undefined symbols for architecture x86_64:
>    "_MPI_Datatype_f2c", referenced from:
>        _dmplexdistributedata_ in plexf.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[2]: ***
> [/Users/aron/sandbox/petsc/arch-darwin-c-debug/lib/libpetsc.dylib] Error 1
> make[2]: Leaving directory `/Users/aron/sandbox/petsc'
> make[1]: *** [gnumake] Error 2
> 
> 
> Looks like the sowing thing, please upgrade:
> 
> https://bitbucket.org/petsc/pkg-sowing/commits/13aaddc2796b1c6bb3e0bcaba5bb8b6c39018b52
> 
> Delete $PETSC_ARCH/conf/sowing and externalpackages/sowing*, then reconfigure.
> 
> Best regards,
> Karli
> 
> 
> 
> On Mon, Oct 28, 2013 at 6:35 PM, Matthew Knepley
> <petsc-maint at mcs.anl.gov <mailto:petsc-maint at mcs.anl.gov>> wrote:
> 
>     On Mon, Oct 28, 2013 at 5:19 PM, Aron Ahmadia <aron at ahmadia.net
>     <mailto:aron at ahmadia.net>> wrote:
> 
>         It's an ordering problem.  When you use '-isysroot', that
>         disables /usr/local/include from the compiler search paths.
> 
>         Since your valgrind checks are before you introduce -isysroot,
>         it passes then, then fails in make.  It's OS X's fault for
>         having a wonky built model, not yours, but we still need to fix
>         it :/
> 
>         ~/s/petsc git:maint ❯❯❯ cc -isysroot
>         /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
>         -mmacosx-version-min=10.9 -c test.c
> 
> 
>     Who the hell is putting sysroot into the command line??? I cannot
>     find it anywhere in the PETSc source or in my build files. Is
>     this come ridiculous CMake BullShit?
> 
>         Matt
> 
>         test.c:1:10: fatal error: 'valgrind/valgrind.h' file not found
>         #include <valgrind/valgrind.h>
>                   ^
>         1 error generated.
>         ~/s/petsc git:maint ❯❯❯ cc -c test.c
> 
>                                ⏎ ◼
>         ~/s/petsc git:maint ❯❯❯ mpicc -c test.c
> 
>         A
> 
> 
>         On Mon, Oct 28, 2013 at 4:01 PM, Aron Ahmadia <aron at ahmadia.net
>         <mailto:aron at ahmadia.net>> wrote:
> 
>             I'll double check.
> 
>             A
> 
> 
>             On Monday, October 28, 2013, Matthew Knepley wrote:
> 
>                 On Mon, Oct 28, 2013 at 2:56 PM, Aron Ahmadia
>                 <aron at ahmadia.net> wrote:
> 
>                     No, your configure script detects it by looking in
>                     /usr/local/include
> 
>                     You neglect to add this in your make.
> 
> 
>                 I just looked at the log. There was no -I/usr/local/include
> 
>                     Matt
> 
>                     A
> 
> 
>                     On Mon, Oct 28, 2013 at 3:55 PM, Matthew Knepley
>                     <petsc-maint at mcs.anl.gov> wrote:
> 
>                         On Mon, Oct 28, 2013 at 2:44 PM, Aron Ahmadia
>                         <aron at ahmadia.net> wrote:
> 
>                             This is a pretty common situation if
>                             somebody has a valgrind from homebrew.
> 
> 
>                         What is a common situation? The preprocessor
>                         finds <valgrind/valgrind.h> but the compiler
>                         does not?
>                         How can that happen on your machine?
> 
>                             Matt
> 
>                             I'd suggest adding '-I/usr/local/include' to
>                             your CFLAGs if you detect a valgrind in this
>                             location.
> 
>                             Cheers,
>                             Aron
> 
> 
> 
> 
>                         --
>                         What most experimenters take for granted before
>                         they begin their experiments is infinitely more
>                         interesting than any results to which their
>                         experiments lead.
>                         -- Norbert Wiener
> 
> 
> 
> 
> 
>                 --
>                 What most experimenters take for granted before they
>                 begin their experiments is infinitely more interesting
>                 than any results to which their experiments lead.
>                 -- Norbert Wiener
> 
> 
> 
> 
> 
>     --
>     What most experimenters take for granted before they begin their
>     experiments is infinitely more interesting than any results to which
>     their experiments lead.
>     -- Norbert Wiener
> 
> 
> 
>