[Ipopt] Problems in compiling for Windows

Mon Aug 3 02:24:33 EDT 2009

Hi Stefan:

I finally was able to compile Ipopt with the Intel Fortran Compiler (version 11).  I then went to config_ipopt.h looking for  #define HAVE_DRAND48, but this is not present in the file.  I anyway uncommented #undef HAVE_DRAND48 and tried a make tests.  But this failed because of unresolved externals drand48 and srand48.  I next tried #defien HAVE_DRAND48 0, but this too was of no use.  This was not a problem when I first compiled Ipopt with Intel version 10 and MSVC 2005.  So I wonder what else I can do to compile the examples and link them with libIpopt.lib. Thanks.

Krish

________________________________
From: Stefan Vigerske <stefan at math.hu-berlin.de>
To: Krish Krishnan <rkrishnan8216 at yahoo.com>
Cc: ipopt mailing list <ipopt at list.coin-or.org>
Sent: Thursday, July 30, 2009 6:19:10 PM
Subject: Re: [Ipopt] Problems in compileing for Windows

Hi,

> Thanks.  I moved the code to another machine that had the Intel Fortran Compiler without MKL.  This time around, the BLAS and LAPACK code was compiled and I had no problem creating libipopt.lib.  So the issue definitely has something to do with the MKL part of the fortran compiler. 

If you do not want Ipopt to use MKL, but build your own blas and lapack,
try configuring with the options --with-blas=BUILD and --with-lapack=BUILD.

> When I try to link to the newly created library, however, I get the linker error unresolved external symbol _drand48 and _srand48.  Do you have any idea if there are any other libraries I should pull in.  (Perhaps these are not part of the Microsoft Visual C++ setup)

Now it depends on which compiler you used on which machine.
drand48 and srand48 are for random number generation and configure
checks which one are available and then uses them.
So probably you did not use the same C++ compiler on your two machines?
You can play around with the #ifdef's in Ipopt/inc/config_ipopt.h to
have Ipopt use a different random number generator function. That is, on
your 2nd machine, you comment out the line #define HAVE_DRAND48, rebuild
and hope that it will work with one of the other two routines.
These are enabled by #define HAVE_STD__RAND and #define HAVE_RAND. Maybe
they are available in the MS VC++ on the first machine.

Stefan

> Thanks
> Krish
> 
> 
> 
> 
> ________________________________
> From: Stefan Vigerske <stefan at math.hu-berlin.de>
> To: Krish Krishnan <rkrishnan8216 at yahoo.com>
> Cc: ipopt mailing list <ipopt at list.coin-or.org>
> Sent: Wednesday, July 29, 2009 4:00:39 PM
> Subject: Re: [Ipopt] Problems in compileing for Windows
> 
> Hi,
> 
>> I am trying to upgrade my version of IpOpt to the current level.  I have the Intel Fortran compiler (Version 11) and the Microsoft Visual Studio (2005).  My environment is Cygwin, and I configure with --enable-doscompile=msvc.  I have used the get statements in the respective ThirdParty directories to get Lapack, Blas, Metis and I also have the latest version of Mumps.
> 
>> 1. When I run configure, I get a warning that the FFLAGS="" does not work, and that it will compile with an empty FFLAGS.
> 
> I cannot see this in your configure output. I see a
>   configure: Fortran compiler options are: -MT -O3 -fpp -nologo
> which looks good to me.
> 
>> 2. The configure command detects Blas and Lapack in the MKL, and so will not build these libraries.  I guess it will use the default version of these that come with MKL.  Is this the correct approach, or is there some way I can force it to build the Blas and Lapack libraries?
> 
> I think so. Your configure output shows
> checking for BLAS in MKL... yes
> checking whether LAPACK is already available with BLAS library... yes
> 
>> 3.  When I try to compile by running make, I get a warning that I am trying to link with static library archive mkl_core.lib and that I should maybe use the shared version.  What should I do at this stage?
>> 4. When at the final stage it tries to build the library, the process seems to pull in a huge number of .obj files (much more than I remember from the previous build).  It hangs at this point and I cannot proceed further and have to kill the process.
> 
> Looks like it is extracting the MKL library, which is then resulting in
> these many object files.
> And the MKL lib is extracted because it has been added to libcoinmumps -
> at the point where you report this warning in step 3:
> 
> /bin/sh ./../../libtool --tag=F77 --mode=link ifort  -MT -O3 -fpp
> -nologo   -Dmetis   -o libcoinmumps.la   dmumps_comm_buffer.lo
> dmumps_struc_def.lo mumps_ooc_common.lo mumps_static_mapping.lo
> dmumps_ooc_buffer.lo dmumps_load.lo dmumps_ooc.lo dmumps_part1.lo
> dmumps_part2.lo dmumps_part3.lo dmumps_part4.lo dmumps_part5.lo
> dmumps_part6.lo dmumps_part7.lo dmumps_part8.lo mumps_part9.lo
> mumps_c.lo mumps_common.lo mumps_orderings.lo mumps_io.lo
> mumps_io_basic.lo mumps_io_thread.lo mumps_io_err.lo mpi.lo mpic.lo
> elapse.lo  mkl_intel_c.lib mkl_sequential.lib mkl_core.lib
> 
> *** Warning: Trying to link with static lib archive mkl_intel_c.lib.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> 
> 
> I am not so sure how to proceed, since I never tried linking to MKL before.
> Maybe you can go into IpOpt_3.6.1_MUMPS/ThirdParty/Mumps and edit the
> Makefile there, trying to prevent adding the files mkl_intel_c.lib
> mkl_sequential.lib mkl_core.lib to the linkline.
> 
> In my linux version of the Makefile, there are the two lines
> libcoinmumps.la: $(libcoinmumps_la_OBJECTS) $(libcoinmumps_la_DEPENDENCIES)
>         $(F77LINK) $(am_libcoinmumps_la_rpath)
> $(libcoinmumps_la_LDFLAGS) $(libcoinmumps_la_OBJECTS)
> $(libcoinmumps_la_LIBADD) $(LIBS)
> 
> Maybe removing $(LIBS) or/and $(libcoinmumps_la_LIBADD) will help?
> 
> Stefan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt

-- 
Stefan Vigerske
Humboldt University Berlin, Numerical Mathematics
http://www.math.hu-berlin.de/~stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20090802/fdcf80e6/attachment.html 