<div>Many thanks for your precious feedback.</div><div>My MPICH install is 64 bit but it seems that for some reason 32 bit VC compiler is invoked (I have both 32 and 64 installed).</div><div>I am clarifying with a local MSVC expert how to control this, will update you later today.</div>
<div>Dominik</div><div><div><br><div class="gmail_quote">On Thu, Jul 22, 2010 at 3:45 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> sh: Warning: win32fe: File Not Found: /cygdrive/c/Program<br>
> Files/MPICH2/lib/amd64/msmpi.lib<br>
<br>
</div>Looks like - if win32fe doesn't find the file - it doesn't try to<br>
convert the path. This is not the cause of his configure failure.<br>
<br>
The primary issue is: [which is much ahead in configure.log]<br>
<br>
>>>>>>>>>>><br>
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/mpi.lib Ws2_32.lib<br>
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/mpi.lib Ws2_32.lib<br>
sh: conftest.obj : error LNK2019: unresolved external symbol _MPI_Init referenced in function _main^M<br>
C:\Users\Dominik\Programs\PETSC-~1.1-P\conftest.exe : fatal error LNK1120: 1 unresolved externals^M<br>
<<<<<<<<<<<<br>
<br>
Here cl is finding the correct library - but not MPI_Init symbol in it.<br>
For whatever reason - libmpi.lib is not compatible.<br>
<font color="#888888"><br>
Satish<br>
</font><div><div></div><div class="h5"><br>
On Thu, 22 Jul 2010, Farshid Mossaiby wrote:<br>
<br>
> I doubt 'cl' can interpret Cygwin paths:<br>
><br>
> cl : Command line warning D9002 : ignoring unknown option<br>
> '/cygdrive/c/Program Files/MPICH2/lib/amd64/msmpi.lib'<br>
><br>
> Shouldn't win32fe convert this path first?<br>
><br>
> Hope this helps.<br>
><br>
> --- On Wed, 7/21/10, Dominik Szczerba <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>> wrote:<br>
><br>
> > From: Dominik Szczerba <<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</a>><br>
> > Subject: Re: [petsc-users] configure problems<br>
> > To: "PETSc users list" <<a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</a>><br>
> > Date: Wednesday, July 21, 2010, 7:01 PM<br>
> > Coming back to the original problem:<br>
> > I tried to compile MPICH2 myself<br>
> > and failed because of wrong version of automake in Cygwin.<br>
> > I then<br>
> > installed the Windows binary available on the mpich2<br>
> > webpage. I<br>
> > configure petsc with:<br>
> ><br>
> > $ ./config/configure.py PETSC_DIR=$PWD<br>
> > PETSC_ARCH=win64-msvc-release<br>
> > --download-c-blas-lapack=1<br>
> > --with-mpi-dir='/cygdrive/c/Program<br>
> > Files/MPICH2' --with-x=0 --with-debugging=0<br>
> > --with-cc='win32fe cl'<br>
> > --with-fc=0<br>
> ><br>
> > to hear at the end (of a very long configuration<br>
> > process...):<br>
> ><br>
> > sh:<br>
> > /cygdrive/c/Users/Dominik/Programs/petsc-3.1-p3/bin/win32fe/win32fe<br>
> > cl -o conftest.exe -MT -wd4996 <br>
> > 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 <br>
> > 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<br>
> > _MPI_Init<br>
> > referenced in function _main<br>
> > C:\Users\Dominik\Programs\PETSC-~1.1-P\conftest.exe : fatal<br>
> > error<br>
> > LNK1120: 1 unresolved externals<br>
> ><br>
> > Any directions why would the configuration look for a<br>
> > 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<br>
> > 2010-07-21 15:54 .<br>
> > drwx------+ 1 SYSTEM SYSTEM 4096<br>
> > 2010-07-21 15:54 ..<br>
> > -rwx------+ 1 SYSTEM SYSTEM 4644<br>
> > 2010-02-22 17:13 TraceInput.lib<br>
> > -rwx------+ 1 SYSTEM SYSTEM 322820 2010-02-22 17:09<br>
> > cxx.lib<br>
> > -rwx------+ 1 SYSTEM SYSTEM 131316 2010-02-22 17:11<br>
> > fmpich2.lib<br>
> > -rwx------+ 1 SYSTEM SYSTEM 136382 2010-02-22 17:13<br>
> > fmpich2g.lib<br>
> > -rwx------+ 1 SYSTEM SYSTEM 1936<br>
> > 2010-02-22 17:13 irlog2rlog.lib<br>
> > -rwx------+ 1 SYSTEM SYSTEM 10430 2010-02-22 16:30<br>
> > mpe.lib<br>
> > -rwx------+ 1 SYSTEM SYSTEM 132128 2010-02-22 16:29<br>
> > mpi.lib<br>
> > -rwx------+ 1 SYSTEM SYSTEM 61286 2010-02-22 16:30<br>
> > 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>><br>
> > wrote:<br>
> > > On Tue, 20 Jul 2010 08:37:18 +1000, Matthew Knepley<br>
> > <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>><br>
> > wrote:<br>
> > >> This would do you absolutely no good. Even Jed's<br>
> > thing needs all the<br>
> > >> information that the configure provides. CMake is<br>
> > 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<br>
> > does<br>
> > > configuration and produces build files for another<br>
> > tool (like make or an<br>
> > > IDE). I see no point in maintaining duplicate<br>
> > configuration systems,<br>
> > > and CMake's scripting language is so attrocious that<br>
> > "replacing"<br>
> > > BuildSystem with CMake script would be a disaster.<br>
> > It's<br>
> > > cross-compilation support is also a bit weak, and<br>
> > there are a pile of<br>
> > > other things that it does poorly (mostly related to<br>
> > pathologically<br>
> > > dysfunctional "Find*.cmake" modules). That doesn't<br>
> > mean it isn't useful<br>
> > > for producing build files.<br>
> > ><br>
> > > Jed<br>
> > ><br>
> > ><br>
> ><br>
><br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>