- 
                Notifications
    
You must be signed in to change notification settings  - Fork 929
 
Description
(this is @hjelmn's fault for bringing up the issue in a face-to-face meeting today. π)
When linking an MPI application against static MPI libraries (e.g., libmpi.a), you need to not only specify -lmpi, you also need to specify -lopen-rte -lopen-pal.
However, when linking an MPI application against dynamic MPI libraries (e.g., libmpi.so), you want to only specify -lmpi -- you do not want to specify -lopen-rte -lopen-pal, because that will make the application dependent upon specific versions of the ORTE / OPAL libraries.  This is bad if you ever want to upgrade your version of Open MPI and not recompile / relink your MPI application: although we honor good backwards compatibility procedures for the MPI and OSHMEM libraries, we do not honor such procedures for ORTE and OPAL.  Meaning: you'll be able to run-time link to the upgraded MPI library, but your application will still try to run-time link against the old ORTE and OPAL libraries (i.e., ldd will show an explicit dependency from your application to the old ORTE and OPAL libraries).
The problem here is that when we make the .pc files (which are generated from configure), we can't necessarily know whether libmpi (and friends) will be static or dynamic -- e.g., we could we building both.  Hence, we can't know whether to list -lopen-rte -lopen-pal in the .pc file or not.
I see a few options, none of which are particularly pleasant:
- Document that the 
.pcfiles are just for dynamic libraries (or just for static libraries)- Meh. Gross.
 
 - Double the number of 
.pcfiles; have ones for dynamic libraries and one for static libraries- This is probably the least gross.
 
 - Disallow building OMPI with 
--enable-static --enable-shared(i.e., only allow building static or dynamic -- but not both), and therefore populate the.pcfile accordingly- Meh. Gross.
 
 
I don't really know what the right answer is here. π¦