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

[Stefan Vigerske]

Hi,

since your email is mostly about the build system, but nothing
particular about Ipopt, let's move over to the buildtools mailing list.

> 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.

This should work. configure tries whether -lblas and -llapack works. If
it doesn't, please open a BuildTools or Ipopt ticket, with the
config.log from the Ipopt subdirectory attached.

> 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 if you do not provide any HSL code, there will still be an empty
libcoinhsl created in ThirdParty/HSL. For some technical reasons, this
is more convenient then omitting the hsl libraries if none of the HSL
codes are provided.

> 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.

One guess is that you did not do a make install in the base directory,
but only in the build directory of Ipopt. There is one step at the very
end of make install of Ipopt where it is assumed that all
.pc-dependencies of Ipopt are installed.

> 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.

The default location was changed because some projects also install data
that is not documentation, so everything related to coin can now be
found under /usr/share/coin, like many other /usr/share/xxx's.

> 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.

The .pc files are always created, and are even parsed during configure,
if pkg-config is disabled.
Disabling pkg-config just disables the use of pkg-config.

> 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?

Yes, part's of. A libcoinhsl was always created, new is that it is
installed. System Blas and Lapack have always been checked for.

> 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.

As said, please open a ticket for this. libblas should be recognized.

> 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?

The idea was not to clutter up /usr/lib with a bunch of coin and
thirdparty libraries. The reason for the extra ThirdParty subdirectory
was to distinguish coin projects from third party projects.
It's like other larger projects that have there own subdirectories in
/usr/lib.
Unfortunately, I did not see how to change the default for libdir in
configure. I had liked it to be $prefix/lib/coin, so a user could change
this. Instead, the default for libdir is still $prefix/lib, and
everything get's installed into $libdir/coin and  $libdir/coin/ThirdParty.

For the Ubuntu specific questions, I have no answer.

Stefan

> 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?
> 
>