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 <[email protected]> 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 <[email protected]> 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
> <[email protected] <mailto:[email protected]>> wrote:
>
> On Mon, Oct 28, 2013 at 5:19 PM, Aron Ahmadia <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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
> <[email protected]> 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
> <[email protected]> wrote:
>
> On Mon, Oct 28, 2013 at 2:44 PM, Aron Ahmadia
> <[email protected]> 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
>
>
>
>
