configure.ac: explicitly set link_all_deplibs=yes
Created by: shintaro-iwasaki
As I wrote, I believe the problem is that Debian's libtool sets link_all_deplibs=no
by default, which stops reading additional dependences in *.la
(for example, libmca_threads.la
in libopen-pal.la
.
Solution
I propose the following patch, which fixes the issue (at least on my Ubuntu 16.04 LTS environment).
Discussions
This changes should be controversial since it changes the root configure.ac
, but I believe this change is beneficial.
My opinions are as follows:
- It can remove inconsistent and hard-to-debug behavior of libtool among Linux distributions (e.g., CentOS vs Debian).
- This can potentially happen in the future if one library (for example, opal) somehow relies on other libraries (not Argobots, but other libraries).
- By design, if library A (i.e.,
libopen-opal.la
) depends on library B (i.e.,libmca_threads.la
) and program C (ompi_info
) depends on library A, I believe program C should be linked to library B automatically by default. - I could not find an easy way with libtool to avoid it (e.g., by specifying a certain
.la
to expand its dependencies recursively)
Note that, as far as I checked, only Debian derivatives set link_all_deplibs=no
(by explicitly adding link_all_deplibs.patch
). I could find many discussions. This libtool behavior is to avoid unnecessary dynamic linking, which would increase the cost of initialization. If it has not become a problem so far on CentOS and OSX, I don't think it will become an issue.
Other possible solutions
As far as I come up with,
- adding
libmca-threads.la
in eachMakefile.am
(https://github.com/open-mpi/ompi/blob/master/ompi/tools/ompi_info/Makefile.am and https://github.com/open-mpi/ompi/blob/master/test/threads/Makefile.am and maybe others) - flattening the contents of
libopen-pal.la
, which includeslibmca-threads.la
and basically all*.la
inopal/
.
I would like to hear any opinion.