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
