[Ipopt] Difficulties with Ipopt 3.9.1 on Linux (Ubuntu 10.04)

[John Pye]

Hi all

Minor changes to the build process from my earlier mail, it was not 
necessary to fake the HSL library after all; the following completed 
successfully:

F77=gfortran ./configure --prefix=/usr --enable-static --enable-shared 
--with-blas-lib=/usr/lib/libblas.so 
--with-lapack-lib=/usr/lib/liblapack.so --enable-pkg-config=no

Problems do arise from the choice of the /usr/lib/coin and 
/usr/lib/coin/ThirdParty locations for the shared libraries, however. In 
particular, my project (ASCEND) makes use of dlopen to load plugins, of 
which IPOPT is one. In order to now successfully load my plugin, I have 
to set LD_LIBRARY_PATH to contain these additional non-standard library 
paths. I *could* use RPATH but that is discouraged (in fact I believe 
disallowed) in Debian-packages software.

It occurred to me that the reason that IPOPT with MUMPS may not work on 
Ubuntu could be the fact that IPOPT makes use of a patched version of 
MUMPS. Does anyone know if the IPOPT can work correctly with an 
unpatched version of MUMPS. I don't know if Ubuntu's version of MUMPS is 
unpatched or not.

Finally, I note that 'pkg-config ipopt --static' gives empty output, 
even though I used ./configure --enable-static. It would be nice to be 
able to use pkg-config to set the necessary linker flags to link 
statically against IPOPT, now that I have a libipopt.a.

I updated our notes about this at
http://ascendwiki.cheme.cmu.edu/IPOPT

Thanks again for reading all this,

Cheers
JP



On 22/12/10 16:06, John Pye wrote:
> Hi all
>
> I am trying to compile my own copy of Ipopt 3.9.1 on Ubuntu 10.04, which
> only offers a possibly-faulty* copy of 3.8.1 in its repositories.
>
> I have downloaded the tarball and unpacked it, then in ThirdParty/MUMPS,
> I successfully ran 'get.Mumps'.
>
> I checked that I have libblas-dev and liblapack-dev installed. I checked
> that I had no libmumps* package installed.
>
> Next I ran
>
> F77=gfortran ./configure --prefix=/usr
> make -j2
> make DESTDIR=/home/john/ipopt-inst install
>
> Firstly, the above does not automatically detect the preinstalled BLAS
> and LAPACK, which would be nice if possible. I added --with-*-lib
> options specifying the paths to the BLAS and LAPACK .so files.
>
> After this, I received some errors at the install stage, relating to
> non-existence of libcoinhsl.so. I don't want to support HSL, because I
> am trying to create a distributable package, so I need a clean way of
> suppressing all actions relating to HSL. I struck upon specifying the
> path to a nonexistent HSL library as a way to do that.
>
> Even with the HSL workaround, I still found some problems at the
> 'install' step relating some some issue with pkgconfig failing to detect
> *.pc files in the local directory. So I disabled pkg-config.
>
> So now, I ended up with:
>
> F77=gfortran ./configure --prefix=/usr --enable-static --enable-shared
> --with-blas-lib=/usr/lib/libblas.so
> --with-lapack-lib=/usr/lib/liblapack.so
> --with-hsl-lib=/usr/lib/libcoinhsl.so --enable-pkg-config=no
> make -j2
> make DESTDIR=/home/john/ipopt-inst install
>
> A comment: it would be very helpful if, as with the SUNDIALS solver
> suite, the ./configure script could give a succinct summary at the end
> showing the components that are going to be supported in the resulting
> build. I am sure that the way I have suppressed HSL, for example, is not
> the correct way.
>
> Another comment: I note that the default location of files in /usr/share
> has changed (I believe) from /usr/share/doc/coin/Ipopt to
> /usr/share/coin/doc/Ipopt. This arrangement of the file heirarchy is
> non-standard compared to how most packages are organised on Linux, in my
> understanding. Package-specific documentation is normally all held
> underneath /usr/share/doc/packagename.
>
> I note that even with the 'enable-pkg-config=no' command added to my
> ./configure command, the resulting 'make install' still installs a file
> ~/ipopt-inst/usr/lib/pkgconfig/ipopt.pc, and additionally, the 'Libs:'
> line in that file contains a reference to /usr/lib/libcoinhsl.so', which
> doesn't exist and will certainly cause problems down the track (again,
> what is the preferred way to safely disable HSL support?). But at least
> this way the installation completes.
>
> I'm not sure, but I think these things have arisen in Ipopt 3.9.1,
> perhaps as a result of the transition to the new COIN Buildtools system
> -- is that right? I believe that I had a build script for 3.9.1 that
> worked fine with just './configure --prefix=/usr'.
>
> It would be really helpful if the Ipopt build process could do a little
> more to support default system configurations such as the one I have
> here. If I have libblas on my system, in /usr/lib, for example, it would
> be good if the default was to use that, rather than to fail because
> ThirdParty/Blas/get.Blas has not been run. Ditto LAPACK.
>
> Finally, is there any need for the default installation of all these
> libraries to be in subdirectories of /usr/lib? Is there a simple way to
> make them all default to /usr/lib, instead of /usr/lib/coin and
> /usr/lib/coin/ThirdParty?
>
> Can anyone point me at another document that indicates a better way to
> build Ipopt 3.9.1 on this version of Ubuntu? Does anyone have a better
> experience with the stanrd repository packages for Ipopt/Mumps on Ubuntu?
>
> Many thanks,
>
> Cheers
> JP
>
>
> * Possibly-faulty: I can build against the version of Ipopt included
> with Ubuntu 10.04 Lucid, but at runtime, it seems to fail to detect
> MUMPS. Perhaps there is an environment variable I can specify to allow
> 'dlopen' to correctly locate the MUMPS library, if it's not already
> hardwired?
>
>

-- 
Dr John Pye
School of Engineering
Australian National University
http://jpye.dyndns.org/