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