[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 12:58, Satish Balay <balay at mcs.anl.gov> wrote:
>
> 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?
>

Makes sense, but both 1.8.4 and 1.8.5p1, with gcc-4.4.4 and gcc-4.5.1, leave
all modules in $PREFIX/include.


> -I/usr/lib/openmpi is from above
>

Yes (my "no" was referring to /usr/local/include), but the wrapper already
specifies this, why should configure give it twice?  Specifying it manually
can cause incorrect header resolution unless it is the very last include
path, in which case its presence is merely redundant.


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

How is this private path even discovered?  Are there really compilers for
which you need to specify private paths?  I understand snooping -lstdc++ and
-lgfortran because neither language depends on the other (in which case the
compiler could get it all right without any flags), but RPATHing private
paths seems very different to me.


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

Thanks, trying this.


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

Thanks.


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


Maybe not, but it seems excessive to specify paths that do not exist or that
have zero modules in them.

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