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

[Stefan Vigerske]

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