[Ipopt] Problems in compiling for Windows

Tue Aug 4 00:53:05 EDT 2009

Hi Stefan:
I did the upgrades, and everything now works like a charm.  Thanks for all the help - it has been very generous of you to guide me on problems with compilers, third party source code etc.
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: Monday, August 3, 2009 6:04:36 PM
Subject: Re: [Ipopt] Problems in compiling for Windows

Hi,

thanks, now things are much clearer.
The drand48 symbols is used in metis, not in ipopt.
There also has been a fix to the metis build system that works exactly
on your issue.
Can you update to Ipopt 3.7.0, or use at least release 1.0.2 of
ThirdParty/Metis?
Or you just run configure again with the option ADD_CFLAGS="-D__VC__".
That should do the same.

The config_ipopt.h file is written by configure.

Stefan

Krish Krishnan wrote:
> Hi Stefan:
> 
> Here is the output when I try to make the test examples:
> 
> 
> test; make test
> make[2]: Entering directory 
> 
> `/cygdrive/d/Ipopt-3.6.1_MUMPS/Ipopt-3.6.1/Ipopt/test'
> /bin/sh ../../libtool --tag=CXX 
> 
> --mode=link cl  -MT -O2 -nologo -EHsc -GR -wd4996 -D_CRT_SECURE_NO_DEPRECATE -DNDEBUG      
> 
> -o hs071_cpp.exe  hs071_main.obj hs071_nlp.obj ../src/Interfaces/libipopt.la -link  
> 
> /NODEFAULTLIB:libc.lib 
> cl -MT -O2 -nologo -EHsc -GR -wd4996 -D_CRT_SECURE_NO_DEPRECATE 
> 
> -DNDEBUG -o hs071_cpp.exe hs071_main.obj hs071_nlp.obj  
> 
> d:/Ipopt-3.6.1_MUMPS/Ipopt-3.6.1/Ipopt/src/Interfaces/.libs/libipopt.lib -link 
> 
> /NODEFAULTLIB:libc.lib
> cl : Command line warning D9035 : option 'o' has been deprecated and 
> 
> will be removed in a future release
> libipopt.lib(initpart.obj) : error LNK2019: unresolved external symbol _drand48 referenced 
> 
> in function ___GrowBisection
> libipopt.lib(graph.obj) : error LNK2001: unresolved external symbol _drand48
> libipopt.lib(minitpart.obj) : error LNK2001: unresolved external symbol _drand48
> libipopt.lib(minitpart2.obj) : error LNK2001: unresolved external symbol _drand48
> libipopt.lib(util.obj) : error LNK2019: unresolved external symbol _srand48 referenced in 
> 
> function ___InitRandom
> hs071_cpp.exe : fatal error LNK1120: 2 unresolved externals
> make[2]: *** [hs071_cpp.exe] Error 2
> make[2]: Leaving directory 
> 
> `/cygdrive/d/Ipopt-3.6.1_MUMPS/Ipopt-3.6.1/Ipopt/test'
> make[1]: *** [unitTest] Error 2
> make[1]: Leaving directory `/cygdrive/d/Ipopt-3.6.1_MUMPS/Ipopt-3.6.1/Ipopt'
> make: *** 
> 
> [tests] Error 2
> 
> 
> 
> Also here are the relevant parts of  config_ipopt.h
> 
> 
> /* Define to 1 if function drand48 is available */
> /* #undef HAVE_DRAND48 */
> 
> DRAND48 is not to be found anywhere else in this file.
> Is this file rewritten with every configure command or with every make command?
> 
> 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: Monday, August 3, 2009 2:10:45 PM
> Subject: Re: [Ipopt] Problems in compiling for Windows
> 
> Hi,
> 
>> 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.
> 
> Can you say where the unresolved externals appear, i.e., which file or
> function wants to use it?
> If there is no #define HAVE_DRAND48 in config_ipopt.h, then Ipopt should
> not use it. See Ipopt/src/Common/IpUtils.cpp, from line 140 on.
> 
> Stefan
> 
>> 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/20090803/0af4b087/attachment.html 