[Ipopt] Installed libipopt.so has undefined symbols

[Andreas Waechter]

Hi Thomas,

Sorry for the delay in response.

Thanks for the explanation.  However, I'm afraid I'm still not sure what 
exactly you would like to have.

In any case, at COIN, we are trying to be as platform independent as we 
can, so that the source code and the configuration and build process works 
on the different flavors of Linux, as well as on Sun, AIX, and Windows, 
etc, but we are trying to do this with a reasonable amount of effort. 
For this reason, we use libtool to generate libraries and executables, and 
I assume that making a change in the direction of what you want would 
require us to mess with libtool.  (Or, maybe a newer version of libtool is 
already doing what you want, but we are currently stuck with 1.5.22.)

If you see a way to get what you want by changing the Ipopt Makefile.am 
files or so (while maintaining portability to all platforms), please send 
me a patch and I can try to incorporate this.

Thanks,

Andreas

On Wed, 27 May 2009, Thomas Moulard wrote:

> 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.
> Best,
> -- 
> Thomas Moulard
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>
>