[Ipopt] Installed libipopt.so has undefined symbols

Thomas Moulard thomas.moulard at gmail.com
Tue May 26 21:19:09 EDT 2009

On Wed, May 27, 2009 at 12:51 AM, Andreas Waechter
<andreasw at watson.ibm.com> wrote:
> Hi Thomas,
> I'm not sure what you mean by "standard way" or by "providing two
> libraries".  The libraries that are missing are system libraries
> pre-installed on your machine.  All code that is compiled by the Ipopt
> Makefiles is included in the libipopt.so (except the code that is not needed
> if you use Ipopt as a library and not an AMPL executable).  There is no way
> to include the missing libraries also in libipopt.so, and it wouldn't be a
> good idea anyway.
> It is not uncommon for software packages (open source or not) to depend on
> system libraries. In your case, Ipopt needs libpthreads.so and liblapack.so.
>  Since this can be different for different users and operating systems, this
> is detected by configure and put into the example Makefiles and the text
> file for convenience, so that a user doesn't have to take care of this by
> hand.

Sorry if I was unclear.

First, I agree that having a library depending on others is totally ok.

Secondly, shared libraries store a list of dependencies to be able to
resolve their dependencies automatically.
When running this line, ld is not going to include lapack & cie. it will
just append more dependencies to this list:
$ g++ -shared -pthread -llapack -lgfortran -lipopt -o libipopt2.so

As you can see the library is almost empty, it is just a ""wrapper"" that adds
the missing dependencies:
$ du libipopt2.so
8       libipopt2.so

Of course it makes Ipopt less difficult to use and make the
building chains of packages depending on Ipopt less complex.

Also, it makes the package dependency tree wrong.
For instance, I am developing a library using Ipopt
but I am not using Lapack.
So my project should /not/ depend on Lapack, but I am forced to
depend on it to provide a "self-contained" library to my users.

If you take a look at Debian or Ubuntu packaging policies,
there is a tool called lintian which is checking that you do not link
against unused libraries. Typically, it emits a warning on my
package because I link against Lapack but I never use it
(ie: there is no Lapack symbol in my library).

Last example: if you take really high level libraries such as those
provided by KDE or Gnome, they have a large and deep
dependency tree that would make the linking extremely complex
for the user if the dependency list was not built incrementally at
each step and by each package.

For all those reasons, I would prefer having a complete dependency
list in libipopt.so.

> (Instead of using those *.txt files, there is another way to do this on
> Linux, by calling a program that outputs a text string with the missing
> library flags.  But we haven't switched to that on COIN [yet?].)

Yes, using pkg-config in Ipopt would be a valid workaround,
I just would prefer avoid resorting to it if it there is a way to directly
solve the problem.

I hope you see my point.
Thomas Moulard

More information about the Ipopt mailing list