[petsc-dev] Why is -I$PETSC_DIR/src/dm/mesh/sieve in CLINKER even when configured without Sieve?

Jed Brown jed at 59A2.org
Tue Oct 12 08:41:23 CDT 2010

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.  It's not necessary to give
-I$PETSC_DIR/$PETSC_ARCH/include twice.

>    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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101012/d908f506/attachment.html>

More information about the petsc-dev mailing list