[Ipopt] Library dependency issue?

[John Pye]

Stefan Vigerske wrote:
> Hi,
>
>> Stefan Vigerske wrote:
>>>> I suspect that maybe there should be library dependencies on BLAS and
>>>> LAPACK, as well,  but maybe I'm wrong there.
>>> If Lapack and Blas are installed on the system and these are used by
>>> Ipopt, then the flags go into ipopt_addlibs_cpp.txt. Otherwise, that
>>> is if Lapack and Blas from ThirdParty are build and used, then the
>>> libs are included into the Ipopt library.
>>
>> Evidently the 'addlibs' thing is somehome comparable to the
>> `ipopt-config --libs` idea, although not yet convenient for use by the
>> end user.
>
> The use should be quite similar, instead of `ipopt-config --libs` you
> do `cat ipopt_addlibs_cpp.txt`.

The problem is knowing where that file is, of course. The benefit of the
'ipopt-config' approach is that provided that script is on your path,
you can easily find everything you need. It makes cross-platform and
cross-distro use of IPOPT a lot simpler.

>
>
>> However what puzzles me here is why I don't see the dependency on LAPACK
>> and BLAS and libfortran when I type 'ldd /usr/local/lib/libipopt.so'...
>> if the IPOPT library uses symbols from those other libraries, why aren't
>> they shown as binary dependencies?
>
> There seem to be a difference between libraries that are "linked in"
> at runtime (these should be seen by ldd) and those that are linked at
> compile time, i.e., when you link the Ipopt library with other objects
> to an executable problem. For the latter you need to specify the flags
> as given in ipopt_addlibs_cpp.txt.
> Probably there is some compiler flags that can tell which .so libs
> should be linked at runtime and therefore would be seen by ldd.
>
> Hope I'm not totally wrong on this issue ;-),

I think that there is case for not having hard dependencies in some
cases, for example when writing plugins with a very well defined API.
For example one might write a firefox plugin in such a way that there is
no dependency on libfirefox.dll or whatever it's called. That way the
plugin can be loaded by whatever version of firefox you want to use it
with. But I don't think that consideration applies here. IPOPT is not
really a plugin for anything, and the risks of ABI incompatibility due
to not having these 'ldd' dependencies is more of a concern IMHO.

Another issue might be the way in which BLAS and LAPACK libraries are
accessed here. Some distros provide a number of different BLASes, eg
ATLAS, GSL and refblas. What happens when a use switches from one to
another - can you be sure that everything will 'just work' with IPOPT in
this case?

Cheers
JP