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,

1. adding libmca-threads.la in each Makefile.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)
2. flattening the contents of libopen-pal.la, which includes libmca-threads.la and basically all *.la in opal/.

I would like to hear any opinion.