[Coin-ipopt] Re: [Coin-discuss] IPOPT: build and linking questions

[damien at khubla.com]

Hi all.

MUMPS can be a long compile depending on how you set it up.  It comes with
4 versions by default:  single and double precision real, and single and
double precision complex.  If you build all 4 it definitely takes a while.
 On *Nix/*Nux, you can change the MUMPS top-level makefile to just build
the double-precision real version which speeds things up a bit.

Dynamically loading a MUMPS .so or dll is feasible and worth considering. 
BUT:  Remember that IPOPT is used on Windows as well (MUMPS was first put
into IPOPT on a Windows build before it was submitted to COIN) and the
syntax for loading dynamic libraries on *Nix/*Nux and Windows is
different.  There's only one major entry point for calling MUMPS, and
making a dynamically-loadable library on both platforms is doable.  I'll
have a look at the code in the next little while and try a few things out.

Damien

> Hi,
>
> shouldn't this go to the IPOPT mailing list?
>
>> To build IPOPT, I have extracted the IPOPT tarball then unzipped MUMPS
>> 4.7.3 to the directory ThirdParty/Mumps/MUMPS and then run "./configure
>> && make && make install" in the top-level IPOPT directory. This is on
>> Fedora 7.
>>
>> After compiling, I get a libipopt.so installed, but it has numerous
>> undefined symbols in it. The missing symbols (using 'nm') come from
>> libgfortran, liblapack, libblas and libpthread. I notice (using 'ldd')
>> that the resulting library is not linked to any of those libraries.
>> Should I really be seeing these undefined symbols? I discovered that in
>> order to compile a trivial test program against libipopt I needed to set
>> compiler flags to link all these libraries, when I would have expected
>> only to have to link to ipopt, and for the other dependencies to follow
>> automatically.
>>
> Yes, you have to see these undefined symbols. When I'm right, then this
> has something todo with using Ipopt in other coin-projects that also
> depend on blas, lapack or others and to avoid double inclusion.
> After the "make install" you get files ipopt_addlibs_cpp.txt and
> ipopt_addlibs_f.txt in the lib subdirectory that tell you exactly which
> libraries you have to link together with the ipopt library, and which
> flags to use, so you can just add a `cat ipopt_addlibs_cpp.txt` on the
> compiler call that links the ipopt library.
>
>> Secondly, thinking about how I can package IPOPT in such a way that it
>> doesn't include statically-linked copies of other software: is it
>> possible that I can build IPOPT to dynamically link against a MUMPS
>> shared library installed somewhere on my system, rather than having
>> IPOPT build its own private copy? It seems that there would need to be
>> more './configure' options to facilitate that. The motivation for this
>> is that MUMPS is a big package and shouldn't need rebuilding for each
>> new IPOPT version. Also, if IPOPT were to eventually become an
>> 'official' RPM or Debian package (license conditions permitting), it
>> would probably not be allowed to include statically linked copies of
>> other libraries.
>>
> I'm not sure I understand this right and can answer this right. If you
> want to link your own MUMPS library together with the Ipopt library,
> then that should work. The symbols defined by libcoinmumps.so are not
> different from them defined in a self-compiled MUMPS package (maybe some
> less files are included in libcoinmumps.la), so if libipopt.so does not
> already include the MUMPS library (I'm not sure about this), then you
> should be able to link your own mumps lib.
> Also note the -with-mumps-dir option of the configure script which you
> can use to specify the directory of your own mumps library.
> It is planned (first for HSL), to make it possible to create an ipopt
> library that contains only the symbols of the linear solver, and then
> load dynamically a library defining this symbol while ipopt is running
> and requires the specific symbol. This should make it possible to create
> an Ipopt binary (or library) that contains no or only free linear
> solvers, and the user can provide a shared library of some (not-so-free)
> linear solver that is then used by Ipopt. However, there are just plans
> to do this, that might take some time...
>
> Best,
> Stefan
> _______________________________________________
> Coin-ipopt mailing list
> Coin-ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-ipopt
>