On Wed, 21 Jul 2010, Dominik Szczerba wrote: > I assume you mean in addition --with-mpi=0, else I am expecting an error > message.
I meant without --with-mpi=0 [or any other MPI option]. In this case configure searches in default paths [assuming MPICH2 was installed in standard location]. Looks like it didn't work for you. So - can you send the corresponding configure.log to petsc-maint? Satish > Configure did not bring up any errors: > > Compilers: > C Compiler: > /cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3/bin/win32fe/win32fe cl -MT > -wd4996 > Linkers: > Static linker: /usr/bin/ar cr > BLAS/LAPACK: > -L/cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3/win64-msvc-release/lib > -L/cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3/win64-msvc-release/lib > -lf2clapack -L/cygdrive/c/Users/Dominik/P > rograms/petsc-3.1-p3/win64-msvc-release/lib > -L/cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3/win64-msvc-release/lib > -lf2cblas > PETSc: > PETSC_ARCH: win64-msvc-release > PETSC_DIR: /cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3 > Clanguage: C > Scalar type: real > Precision: double > Memory alignment: 16 > shared libraries: disabled > dynamic libraries: disabled > xxx=========================================================================xxx > Configure stage complete. Now build PETSc libraries with: > make PETSC_DIR=/cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3 > PETSC_ARCH=win64-msvc-release all > xxx=========================================================================xxx > > Building was also successful. Test run OK (with 1 MPI process) > > My LIB: > > C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;C:\Program > Files (x86)\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\Microsoft > SDKs\Windows\v6.0A\lib; > > Many thanks for any hints how to get a usable MPICH2 installation, > Dominik > > On Wed, Jul 21, 2010 at 6:09 PM, Satish Balay <balay at mcs.anl.gov> wrote: > > > Try: > > > > ./config/configure.py PETSC_DIR=$PWD PETSC_ARCH=win64-msvc-release > > --download-c-blas-lapack=1 --with-x=0 --with-debugging=0 --with-cc='win32fe > > cl' --with-fc=0 > > > > If it fails - send us configure.log at petsc-maint at mcs.anl.gov > > > > BTW: What do you have in your LIB env variable? [MS search this path for > > libraries by default] > > > > echo $LIB > > > > Satish > > > > On Wed, 21 Jul 2010, Dominik Szczerba wrote: > > > > > Coming back to the original problem: I tried to compile MPICH2 myself > > > and failed because of wrong version of automake in Cygwin. I then > > > installed the Windows binary available on the mpich2 webpage. I > > > configure petsc with: > > > > > > $ ./config/configure.py PETSC_DIR=$PWD PETSC_ARCH=win64-msvc-release > > > --download-c-blas-lapack=1 --with-mpi-dir='/cygdrive/c/Program > > > Files/MPICH2' --with-x=0 --with-debugging=0 --with-cc='win32fe cl' > > > --with-fc=0 > > > > > > to hear at the end (of a very long configuration process...): > > > > > > sh: /cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3/bin/win32fe/win32fe > > > cl -o conftest.exe -MT -wd4996 conftest.o /cygdrive/c/Program\ > > > Files/MPICH2/lib/amd64/msmpi.lib Ws2_32.lib > > > Executing: > > /cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3/bin/win32fe/win32fe > > > cl -o conftest.exe -MT -wd4996 conftest.o /cygdrive/c/Program\ > > > Files/MPICH2/lib/amd64/msmpi.lib Ws2_32.lib > > > sh: Warning: win32fe: File Not Found: /cygdrive/c/Program > > > Files/MPICH2/lib/amd64/msmpi.lib > > > cl : Command line warning D9002 : ignoring unknown option > > > '/cygdrive/c/Program Files/MPICH2/lib/amd64/msmpi.lib' > > > conftest.obj : error LNK2019: unresolved external symbol _MPI_Init > > > referenced in function _main > > > C:\Users\Dominik\Programs\PETSC-~1.1-P\conftest.exe : fatal error > > > LNK1120: 1 unresolved externals > > > > > > Any directions why would the configuration look for a nonexistent > > > library? The contents of the installation folder are: > > > > > > $ ls -la /cygdrive/c/Program\ Files/MPICH2/lib/ > > > total 808 > > > drwx------+ 1 SYSTEM SYSTEM 4096 2010-07-21 15:54 . > > > drwx------+ 1 SYSTEM SYSTEM 4096 2010-07-21 15:54 .. > > > -rwx------+ 1 SYSTEM SYSTEM 4644 2010-02-22 17:13 TraceInput.lib > > > -rwx------+ 1 SYSTEM SYSTEM 322820 2010-02-22 17:09 cxx.lib > > > -rwx------+ 1 SYSTEM SYSTEM 131316 2010-02-22 17:11 fmpich2.lib > > > -rwx------+ 1 SYSTEM SYSTEM 136382 2010-02-22 17:13 fmpich2g.lib > > > -rwx------+ 1 SYSTEM SYSTEM 1936 2010-02-22 17:13 irlog2rlog.lib > > > -rwx------+ 1 SYSTEM SYSTEM 10430 2010-02-22 16:30 mpe.lib > > > -rwx------+ 1 SYSTEM SYSTEM 132128 2010-02-22 16:29 mpi.lib > > > -rwx------+ 1 SYSTEM SYSTEM 61286 2010-02-22 16:30 rlog.lib > > > > > > Best regards, > > > Dominik > > > > > > On Tue, Jul 20, 2010 at 12:44 AM, Jed Brown <jed at 59a2.org> wrote: > > > > On Tue, 20 Jul 2010 08:37:18 +1000, Matthew Knepley <knepley at > > > > gmail.com> > > wrote: > > > >> This would do you absolutely no good. Even Jed's thing needs all the > > > >> information that the configure provides. CMake is exactly what it > > > >> says, make. It does no configuration > > > > > > > > This isn't true, CMake isn't a build system at all, it does > > > > configuration and produces build files for another tool (like make or > > an > > > > IDE). I see no point in maintaining duplicate configuration systems, > > > > and CMake's scripting language is so attrocious that "replacing" > > > > BuildSystem with CMake script would be a disaster. It's > > > > cross-compilation support is also a bit weak, and there are a pile of > > > > other things that it does poorly (mostly related to pathologically > > > > dysfunctional "Find*.cmake" modules). That doesn't mean it isn't > > useful > > > > for producing build files. > > > > > > > > Jed > > > > > > > > > > > > > >
