[petsc-dev] Why is -I$PETSC_DIR/src/dm/mesh/sieve in CLINKER even when configured without Sieve?
bsmith at mcs.anl.gov
Tue Oct 12 09:18:02 CDT 2010
On Oct 12, 2010, at 8:41 AM, Jed Brown wrote:
> On Tue, Oct 12, 2010 at 15:30, Barry Smith <bsmith at mcs.anl.gov> wrote:
> We could try to filter out empty directories and non-existent directories at the end, just before printing to the petscvariables file
> Satish fixed the nonexistant /usr/local showing up from valgrind. I think it's better to fix packages that may be injecting non-existent directories than to filter them out at the end.
Agreed. This is why you should send your configure.log to petsc-maint so we can "fix packages that may be injecting non-existent directories". We cannot do that in the abstract, only by tracking down them through configure.log
> It's not necessary to give -I$PETSC_DIR/$PETSC_ARCH/include twice.
True. If it is still happening then send configure.log
> The reason we list directories that "the MPI compiler wrappers" already use is for mixed languages. We cannot be sure that all the linkers (c,c++, fortran) use each others libraries/directories so we generate a list of all that any of them use. It would be possible, though I think too fragile and not worth doing for a couple of unneeded -L's to try to, for each language, remove those that the compiler for that language already supports internally.
> Okay, I'm not too concerned by redundant MPI paths as long as they come *last* (in my case above, the nonexistent /usr/local/include came *after* MPI directories which is definitely bad).
> I still don't understand manually passing the private (not MPI-related) compiler path /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1. Maybe this is in case the Fortran compiler comes from a different vendor, but we still need to be able to locate libgcc.a. I guess I don't have a good solution to that, but it still feels icky.
Send configure.log I think this is unfixable but without configure.log we won't know.
More information about the petsc-dev