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>
