I doubt 'cl' can interpret Cygwin paths: cl : Command line warning D9002 : ignoring unknown option '/cygdrive/c/Program Files/MPICH2/lib/amd64/msmpi.lib'
Shouldn't win32fe convert this path first? Hope this helps. --- On Wed, 7/21/10, Dominik Szczerba <dominik at itis.ethz.ch> wrote: > From: Dominik Szczerba <dominik at itis.ethz.ch> > Subject: Re: [petsc-users] configure problems > To: "PETSc users list" <petsc-users at mcs.anl.gov> > Date: Wednesday, July 21, 2010, 7:01 PM > 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 > > > > >