<div class="gmail_quote">On Tue, Oct 12, 2010 at 15:30, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2mf">We could try to filter out empty directories and non-existent directories at the end, just before printing to the petscvariables file<br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":2mf">
    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.</div>
</blockquote></div><div><br></div><div>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).</div>
<div><br></div><div>I still don't understand manually passing the private (not MPI-related) compiler path /usr/lib/gcc/x86_64-unknown-linux-gnu/<a href="http://4.5.1.">4.5.1.</a>  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.</div>
<div><br></div><div>Jed</div>