[Ipopt] Resolved issues when compiling with MinGW GCC 4.3.0

[Andreas Waechter]

Hi Anders,

Thank you for your email, and also for posting the corresponding tickets 
today.  I will incorporate your suggestions into the development ("trunk") 
and stable branch in the Ipopt repository, and it should be then included 
in the next release that I will create at some point.

Thanks for describing those issues, and even better, providing the 
solutions at the same time! :-)

Andreas

On Thu, 2 Oct 2008, Gustafsson, Anders wrote:

> This is my first entry in this mailing list, so first of all I would
> like to take the opportunity to thank the people who have developed this
> terrific large-scale optimizer IPOPT and made it available as open
> source.
>
>
>
> I thought I should report my findings when compiling Ipopt-3.5.4 on
> Windows XP using MSYS 1.0.10 and MinGW (GCC version 4.3.0). The linear
> solver is MUMPS, version 4.8.1.
>
>
>
> When compiling IpTripletToCSRConverter.cpp in the
> Algorithm/LinearSolvers directory, I get the following error message:
>
>
>
> IpTripletToCSRConverter.cpp:63:   instantiated from here
>
> IpTripletToCSRConverter.hpp:105: error: 'void
> Ipopt::TripletToCSRConverter::TripletEntry::operator=(const
> Ipopt::TripletToCSRConverter::TripletEntry&)' is private
>
>
>
> This is the failing code line in IpTripletToCSRConverter.cpp:
>
>
>
>    std::list<TripletEntry> entry_list(nonzeros);
>
>
>
> The TripletEntry assignment operator is declared private in
> IpTripletToCSRConverter.hpp. I notice in the code there is a public
> dummy copy constructor for the inner class TripletEntry, and I assume
> that this copy constructor is defined to make the TripletEntry list
> construction possible. But it seems like the std::list implementation in
> GCC 4.3.0 uses the assignment operator, hence the compilation failure.
> (I have not verified this, but it seems plausible to me.)
>
>> From what I can tell, the TripletEntry class is local to the
> TripletToCSRConverter class, and the data members in TripletEntry are
> simple integers (typedef int Index). Then, would it not be OK to let the
> compiler implicitly define both the copy constructor and the assignment
> operator? That is, remove the definition "TripletEntry(const
> TripletEntry&)" and the declaration "void operator=(const
> TripletEntry&)" from the TripletEntry class? With these modifications,
> the code compiles flawlessly, and the optimizer seems to run as
> intended.
>
>
>
> Another issue: when trying to build the executable in
> examples/ScalableProblems, I got the following error message:
>
>
>
> $ make
>
> g++ -O3 -fomit-frame-pointer -pipe -DNDEBUG -pedantic-errors -Wimplicit
> -Wparentheses -Wreturn-type -Wcast-qual -Wall -Wpointer-arith
> -Wwrite-strings -Wconversion -Wno-unknown-pragmas   -I`echo
> /c/GNU/Ipopt-3.5.4/include/coin` -c -o solve_problem.o `test -f
> 'solve_problem.cpp' || echo './'`solve_problem.cpp
>
> solve_problem.cpp: In function 'int main(int, char**)':
>
> solve_problem.cpp:140: error: 'strcmp' was not declared in this scope
>
> make: *** [solve_problem.o] Error 1
>
>
>
> The function 'strcmp' is really a member of cstring/string.h, which is
> not explicitly included in 'solve_problem.cpp'. I think that most
> compilers implicitly include cstring/string.h when cstdlib/stdlib.h is
> included, and therefore this error normally does not show up. However,
> to be on the safe side with all compilers, cstring/string.h needs to be
> explicitly included.
>
>
>
> To successfully compile, I simply added the following code to
> 'solve_problem.cpp':
>
>
>
> #ifdef HAVE_CSTRING
>
> # include <cstring>
>
> #else
>
> # ifdef HAVE_STRING_H
>
> #  include <string.h>
>
> # else
>
> #  error "don't have header file for string"
>
> # endif
>
> #endif
>
>
>
> I hope these findings can be of help to other users of IPOPT. Also, if
> you agree with my suggested modifications, I would of course be happy to
> see my suggestions implemented in the regular IPOPT code base.
>
>
> Anders Gustafsson
> Physics Support Coordinator
> Nucletron Scandinavia AB
> Office: +46 18 565073
> Mobile: +46 70 579 50 73
>
> anders.gustafsson at se.nucletron.com
> Visit our website: http://www.nucletron.com/
>
> --------------------------------------------------------------------------
> This e-mail and any attachment sent with it are intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Nucletron Scandinavia AB rules out any and every liability resulting from any electronic transmission.
> --------------------------------------------------------------------------
>
>
>