[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 16:18, Barry Smith <bsmith at mcs.anl.gov> wrote:

> >  It's not necessary to give -I$PETSC_DIR/$PETSC_ARCH/include twice.
>
>    True. If it is still happening then send configure.log
>

This particular issue isn't specific to me, it's in all the nightlies and
must happen on your machine too, which is why I didn't bother sending the
full log. e.g.

Using include paths:
-I/usr/home/balay/petsc-dev/arch-freebsd-pkgs-opt/include
-I/usr/home/balay/petsc-dev/include
-I/usr/home/balay/petsc-dev/arch-freebsd-pkgs-opt/include
-I/usr/local/include


> > I still don't understand manually passing the private (not MPI-related)
> compiler path /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1.  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.
>
>    Send configure.log I think this is unfixable but without configure.log
> we won't know.


This also isn't specific to me, every one of your configure.logs is equally
relevant.  I get Satish's point that these paths end up being required when
linking mixed languages with mixed vendors.  So unless someone writes a
special case for matching vendors, these paths will always exist.  It may be
hard to make that special case robust, so perhaps it's not worth "fixing".
 The only functional downside (provided these system paths actually come
last, which is happening correctly post-valgrind-issue) is needing to relink
after upgrading a compiler.

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