[Ipopt] Problems in compiling for Windows

Krish Krishnan rkrishnan8216 at yahoo.com
Mon Aug 3 08:20:53 EDT 2009


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/9f885547/attachment-0001.html 


More information about the Ipopt mailing list