[Ipopt] Help with IPOPT linking problems on Windows MSVC/IntelC++

Krish Krishnan rkrishnan8216 at yahoo.com
Mon Aug 25 02:09:26 EDT 2008


Hi:



----- Original Message ----
From: "ipopt-request at list.coin-or.org" <ipopt-request at list.coin-or.org>
To: ipopt at list.coin-or.org
Sent: Sunday, August 24, 2008 9:30:01 PM
Subject: Ipopt Digest, Vol 44, Issue 20

Hi :
I compile using MSVC and Intel Fortran using the configure script under Cygwin..  I created both release and debug versions of the library.

I now uses the compiled libraries in visual studio.  After some experimentation, the following worked for me.  For the debug version, I disable MSVCRTD.LIB, MSVCPRTD.LIB and LIBCMT.LIB.  For the release version I disable MSVCRT.LIB and MSVCPRT.LIB.

Hope this helps.

Krish



Send Ipopt mailing list submissions to
    ipopt at list.coin-or.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://list.coin-or.org/mailman/listinfo/ipopt
or, via email, send a message with subject or body 'help' to
    ipopt-request at list.coin-or.org

You can reach the person managing the list at
    ipopt-owner at list.coin-or.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ipopt digest..."


Today's Topics:

   1. Re: Help with IPOPT linking problems on Windows MSVC/Intel
      C++ (Jesse Perla)
   2. Re: Help with IPOPT linking problems on Windows MSVC/Intel
      C++ (Stefan Vigerske)


----------------------------------------------------------------------

Message: 1
Date: Sat, 23 Aug 2008 13:04:10 -0400
From: "Jesse Perla" <jesseperla at gmail.com>
Subject: Re: [Ipopt] Help with IPOPT linking problems on Windows
    MSVC/Intel    C++
To: "Damien Hocking" <damien at khubla.com>,    "COIN-IPOPT Mailing List"
    <ipopt at list.coin-or.org>
Message-ID:
    <9b4746990808231004t6c51552ckac46ec3f2d51dc31 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hey guys:

Based on Damien's suggestion I tried different permutations of nodefaultlib
to no avail.  I am taking one last crack at linking to this in a debug build
before getting into the building world (release is working sufficiently for
now I believe)
* I changed the /Code Generation/Runtime Library to Multi-threaded Debug
(/MTd)  from the default dll version
* I link to just libipopt.lib (adding in others didn't seem to help).
* without setting any /nodefaultlib I get a bunch of duplicates like the
following, all mentioned are from libcmt.lib such as:
1>LIBCMT.lib(invarg.obj) : error LNK2005: __initp_misc_invarg already
defined in LIBCMTD.lib(invarg.obj)
1>LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson already defined in
LIBCMTD.lib(invarg.obj)

* With setting /NODEFAULTLIB:libcmt I get a bunch of unresolved symbols:
1>cpp_example.cpp
1>Linking... (Intel C++ Environment)
1>xilink: executing 'link'
1>libipopt.lib(IpSumMatrix.obj) : error LNK2001: unresolved external symbol
__invalid_parameter_noinfo
....

* With setting /NODEFAULTLIB:libcmtd I get 4 unresolved symbols:
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other
libs; use /NODEFAULTLIB:library
1>libcpmtd.lib(stdthrow.obj) : error LNK2019: unresolved external symbol
__CrtDbgReportW referenced in function "void __cdecl
std::_Debug_message(wchar_t const *,wchar_t const *,unsigned int)"
(?_Debug_message at std@@YAXPB_W0I at Z)
1>libcpmtd.lib(xdebug.obj) : error LNK2019: unresolved external symbol
__malloc_dbg referenced in function "void * __cdecl operator new(unsigned
int,struct std::_DebugHeapTag_t const &,char *,int)"
(??2 at YAPAXIABU_DebugHeapTag_t@std@@PADH at Z)
1>libcpmtd.lib(xdebug.obj) : error LNK2019: unresolved external symbol
__free_dbg referenced in function "void __cdecl operator delete(void
*,struct std::_DebugHeapTag_t const &,char *,int)"
(??3 at YAXPAXABU_DebugHeapTag_t@std@@PADH at Z)
1>libcpmtd.lib(_tolower.obj) : error LNK2019: unresolved external symbol
__calloc_dbg referenced in function __Getctype
1>C:\working\libraries\etk\examples\test_etk_coin\Debug/test_etk_coin.exe :
fatal error LNK1120: 4 unresolved externals

* With Setting /NODEFAULTLIB:libcmt and then /NODEFAULTLIB:libcmtd (or a
superset of those) I get an enormous number of unresolved symbols

If anyone has any last minute suggestions on a permuation, I would love to
give it a shot.  Otherwise, do you suggest I try to make the windows
binaries with Visual Studio or MingGW instructions?  Which do you think is
easier to get working for building the 4 permutations of builds
(debug/release and multithreaded/multithreaded-dll)?  Also, do you expect
that I will have trouble with the multi-threaded dll build?  I am using /MDd
for my other libraries and am worried I may run into the opposite problem
changing those over.


On Thu, Aug 21, 2008 at 5:40 PM, Damien Hocking <damien at khubla.com> wrote:

>  Ye olde duplicate symbols.  MS has 2 sets of libraries that supply C/C++
> runtimes.  You might need to specify exactly which libs you don't want as
> part of the project extra command-line options.
>
>
>
> /NODEFAULTLIB:libcmt /NODEFAULTLIB:libcmtd /NODEFAULTLIB:libcpmt
> /NODEFAULTLIB:libcpmtd will remove the libc threaded and unthreaded debug
> and release libs deom your build, and it should then just use the msvcrt
> runtimes.
>
>
>
> Libifcorert.lib is an Intel Fortran runtime that comes with the compiler.
>
>
>
> Damien
>  ------------------------------
>
> *From:* ipopt-bounces at list.coin-or.org [mailto:
> ipopt-bounces at list.coin-or.org] *On Behalf Of *Jesse Perla
> *Sent:* Thursday, August 21, 2008 3:28 PM
> *To:* COIN-IPOPT Mailing List
> *Subject:* [Ipopt] Help with IPOPT linking problems on Windows MSVC/Intel
> C++
>
>
>
> I am trying to get the IPOPT samples running in MSVC or Intel C++ and am
> running into linking errors.  Here are my steps:
>
> 1. Downloading the binaries available on:
> http://www.coin-or.org/download/binary/OS/  Note that the only binaries
> in: http://www.coin-or.org/download/binary/Ipopt/   are for linux64.
>  a. (BTW, as a general consideration I would say that people may be
> overestimating the applicability of cygwin vs. the native Intel or microsoft
> compilers when on windows.  Getting a development environment working with
> an optimizing compiler on cygwin is very difficult).
> 2. The sample program I am getting is from the source in Ipopt-3.4.2.  I am
> trying out the cpp_example.cpp mentioned in:
> http://www.coin-or.org/Ipopt/documentation/node32.html
> 3. Since the makefile for this is for cygwin, I need to create my own.  .
>   a. I first added the 3 source files into a new project
>   b. I ensured that the include path to the headers in the binary
> distribution and the libraries directory were set properly.
>   c. I added libipopt.lib to the linker inputs.
> 4. I hit compile.  All of the source compiled fine, but when linking, it
> stated that a whole bunch of functions were already defined in core
> libraries such as: MSVCRTD.lib.  See notes below for some examples of these.
> 5. To see if it would help, I added the names of the libraries to the
> "ignore specific library" list in the linker input options.  No luck.
> 6. I tried with Intel C++ vs. MSVC.  No difference.
> 7. I tried the "no default libs" selection in the project.  A million
> unresolved errors
> 8. I tried opening the example that came in the binary distribution: called
> osTestCode.
>   a. Had a different link error for a library that wasn't in the binary
> libs directory: 1>LINK : fatal error LNK1181: cannot open input file
> 'libifcorert.lib'
>   b. That probably is an unrelated error, but why isn't this in the
> distribution, and does it have anything to do with the empty IFORT directory
> in the libs?
>
> Can anyone help?  Below is a subset of the linker output to get the point:
>
> 1>------ Rebuild All started: Project: test_etk_coin, Configuration: Debug
> Win32 ------
> 1>Deleting intermediate files and output files for project 'test_etk_coin',
> configuration 'Debug|Win32'.
> 1>Compiling with Intel(R) C++ 10.1.020 [IA-32]... (Intel C++ Environment)
> 1>cpp_example.cpp
> 1>MyNLP.cpp
> 1>Compiling manifest to resources... (Microsoft VC++ Environment)
> 1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
> 1>
> 1>Copyright (C) Microsoft Corporation.  All rights reserved.
> 1>
> 1>
> 1>Linking... (Intel C++ Environment)
> 1>xilink: executing 'link'
> 1>msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: __thiscall
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> >::basic_string<char,struct
> std::char_traits<char>,class std::allocator<char> >(char const *)"
> (??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at PBD@Z)
> already defined in libipopt.lib(IpIpoptApplication.obj)
> 1>msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: class
> std::locale::facet * __thiscall std::locale::facet::_Decref(void)"
> (?_Decref at facet@locale at std@@QAEPAV123 at XZ) already defined in
> libipopt.lib(IpIpoptApplication.obj)
> 1>libcpmt.lib(locale0.obj) : error LNK2005: "void __cdecl
> _AtModuleExit(void (__cdecl*)(void))" (?_AtModuleExit@@YAXP6AXXZ at Z)
> already defined in msvcprtd.lib(locale0_implib.obj)
> ....
> 1>libcpmt.lib(xlock.obj) : error LNK2005: "public: __thiscall
> std::_Lockit::~_Lockit(void)" (??1_Lockit at std@@QAE at XZ) already defined in
> msvcprtd.lib(MSVCP90D.dll)
> 1>LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson already defined
> in MSVCRTD.lib(MSVCR90D.dll)
> 1>LIBCMT.lib(setlocal.obj) : error LNK2005: __configthreadlocale already
> defined in MSVCRTD.lib(MSVCR90D.dll)
> 1>LIBCMT.lib(tidtable.obj) : error LNK2005: __encode_pointer already
> defined in MSVCRTD.lib(MSVCR90D.dll)
> 1>LIBCMT.lib(tidtable.obj) : error LNK2005: __decode_pointer already
> defined in MSVCRTD.lib(MSVCR90D.dll)
> 1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __amsg_exit already defined in
> MSVCRTD.lib(MSVCR90D.dll)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20080823/5675af8b/attachment-0001.html 

------------------------------

Message: 2
Date: Sat, 23 Aug 2008 19:53:43 +0200
From: Stefan Vigerske <stefan at vigerske.de>
Subject: Re: [Ipopt] Help with IPOPT linking problems on Windows
    MSVC/Intel C++
To: ipopt at list.coin-or.org
Cc: Jesse Perla <jesseperla at gmail.com>
Message-ID: <48B04EA7.50507 at vigerske.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

> Based on Damien's suggestion I tried different permutations of nodefaultlib
> to no avail.  I am taking one last crack at linking to this in a debug build
> before getting into the building world (release is working sufficiently for
> now I believe)
>  * I changed the /Code Generation/Runtime Library to Multi-threaded Debug
> (/MTd)  from the default dll version
>  * I link to just libipopt.lib (adding in others didn't seem to help).

I lost track already. How was that one build, multithreaded or 
multithreaded-debug?

> If anyone has any last minute suggestions on a permuation, I would love to
> give it a shot.  Otherwise, do you suggest I try to make the windows
> binaries with Visual Studio or MingGW instructions?  Which do you think is
> easier to get working for building the 4 permutations of builds
> (debug/release and multithreaded/multithreaded-dll)?  Also, do you expect
> that I will have trouble with the multi-threaded dll build?  I am using /MDd
> for my other libraries and am worried I may run into the opposite problem
> changing those over.

If possible, then you should have all libraries build with the same 
flag, that is all debug, or all multithreaded-dll, or whatever...
If you build Ipopt with Visual Studio and wanna use MUMPS, then I don't 
know how VS will know how to compile this Fortran90 package.
When you follow the MinGW instruction, you can overwrite compiler flags 
(CFLAGS, CXXFLAGS, FFLAGS) to make sure that they all use the same 
-MT/-MTd/... flags. It should be correct already for the default build 
(=-MT), but for the debug build I'm not sure.

Stefan


------------------------------

_______________________________________________
Ipopt mailing list
Ipopt at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/ipopt


End of Ipopt Digest, Vol 44, Issue 20
*************************************



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20080824/8e8373af/attachment-0001.html 


More information about the Ipopt mailing list