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

[Satish Balay]

On Tue, 12 Oct 2010, Jed Brown wrote:

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

hdf5 dumps .mod files in prefix/lib dir [atleast the version used in
--download-hdf5]. And you specified '--with-hdf5-dir=/usr'. So
configure adds -I/usr/lib?


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

-I/usr/lib/openmpi is from above


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

checkCLibraries() checkFortranLibraries() have no way of knowing that
some of the options are superflus. Maybe these are superflus on
linux/bsd - but not on AIX or other wierd machine/compiler combo. So
we didn't hesitate to add in things here - just so that configure works
with all machines/compilers.

And if one doesn't want that - they can use '--with-clib-autodetect=0
--with-fortranlib-autodetect=0 --with-cxxlib-autodetect=0
LIBS=-lgfortran' or something like that to disable this autodetect
code - and specify the exact comaptibility library list [for the
c,fortran compilers specified to configure] with LIBS option.

> 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']

Fixed now.

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

Hm - perhaps configure doesn't keep track of module paths separately
for each package - which it needs to?

Satish