<div class="gmail_quote">On Tue, Oct 12, 2010 at 05:55, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov">balay@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;">
<br>
<div class="im">On Tue, 12 Oct 2010, Jed Brown wrote: </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> How about /usr/include (which is a system directory and need not,</div>
<div class="im">
> indeed should not, be specified explicitly)<br>
<br>
</div>-I/usr/lib -I/usr/include [and perhaps -L/usr/lib] are the artifacts<br>
of '--with-hdf5-dir=/usr --with-parmetis-dir=/usr' etc..<br>
<br>
I guess garbage in garbage out here. [not sure if configure should<br>
overide user speified wish here..]<br></blockquote><div><br></div><div>I understand the -I/usr/include, but why -I/usr/lib?  Some Fortran 90 compilers put modules in /usr/lib, but GCC does not (at least recently) and this is compiling C.  Everything certainly builds correctly without it, and /usr/lib is definitely not searched for headers.  With autoconf, I believe the convention is that --with-foo=/path will end up compiling with -I/path/include and -L/path/lib, but --with-foo will just try to compile and link (letting the compiler search system paths).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> and /usr/lib/openmpi which has no C headers in it and really<br>
> shouldn't be specified either.<br>
<br>
</div>This must be coming from your MPI install. I suspect<br>
/usr/local/include is also from there.  check 'mpicc -show' and<br>
'mpif90 -show'. Configure.log will have details.</blockquote><div><br></div><div>Not from MPI:</div><div><br></div><div><div>$ mpicc -show</div><div>gcc -pthread -L/usr/lib/openmpi -lmpi -lnuma -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl</div>
</div><div><br></div><div><div>$ mpif90 -show</div><div>/usr/bin/gfortran -I/usr/include -pthread -I/usr/lib/openmpi -L/usr/lib/openmpi -lmpi_f90 -lmpi_f77 -lmpi -lnuma -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl</div>
</div><div><br></div><div>This -I/usr/include show up because /usr/include is not searched for modules by default.  The wrapper (yes, I hate wrappers, but they seem to be the most reliable way to use MPI) already specifies the correct paths and libraries, why does PETSc have to snoop them and then specify them a second time.  In particular, if they come anywhere but last, then they could actually cause incorrect header and library resolution.  And why do I always have</div>
<div><br></div><div>  -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1</div><div><br></div><div>which will force me to relink when I upgrade to 4.5.2, even though GCC promises (and every other package believes) that they will not change the ABI on a subminor release?</div>
<div> </div><div>The /usr/local path seems to be coming from a valgrind check:</div><div><br></div><div>      Checking for headers Package specific search directory VALGRIND: ['/usr/local/include', '/usr/include', '/usr/lib/openmpi']</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">>  Why can't I have -I$PETSC_DIR/$PETSC_ARCH/include<br>
> -I$PETSC_DIR/include and *nothing* else unless I have packages in<br>
> non-system directories?<br>
<br>
</div>The additonal stuff is the language inter-operability sutff - and some<br>
of the external package dependency stuff.</blockquote><div><br></div><div>Do F90 modules ever need to be visible when using the C compiler?</div><div><br></div><div>Jed</div></div>