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

[John Pye]

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