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

[Jed Brown]

On Tue, Oct 12, 2010 at 05:55, Satish Balay <balay at mcs.anl.gov> wrote:

>
> On Tue, 12 Oct 2010, Jed Brown wrote:
>
> How about /usr/include (which is a system directory and need not,
> > indeed should not, be specified explicitly)
>
> -I/usr/lib -I/usr/include [and perhaps -L/usr/lib] are the artifacts
> of '--with-hdf5-dir=/usr --with-parmetis-dir=/usr' etc..
>
> I guess garbage in garbage out here. [not sure if configure should
> overide user speified wish here..]
>

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


> > and /usr/lib/openmpi which has no C headers in it and really
> > shouldn't be specified either.
>
> This must be coming from your MPI install. I suspect
> /usr/local/include is also from there.  check 'mpicc -show' and
> 'mpif90 -show'. Configure.log will have details.


Not from MPI:

$ mpicc -show
gcc -pthread -L/usr/lib/openmpi -lmpi -lnuma -ldl -Wl,--export-dynamic -lnsl
-lutil -lm -ldl

$ mpif90 -show
/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

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

  -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1

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?

The /usr/local path seems to be coming from a valgrind check:

      Checking for headers Package specific search directory VALGRIND:
['/usr/local/include', '/usr/include', '/usr/lib/openmpi']

>  Why can't I have -I$PETSC_DIR/$PETSC_ARCH/include
> > -I$PETSC_DIR/include and *nothing* else unless I have packages in
> > non-system directories?
>
> The additonal stuff is the language inter-operability sutff - and some
> of the external package dependency stuff.


Do F90 modules ever need to be visible when using the C compiler?

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