Static builds produce dysfunctional mpicc wrapper

[rhc54]

Was just told this:

Static building of ompi3.1.x produces an mpicc wrapper that does not link applications properly. It
misses a -lpmix right after the -lopen-pal. The defect is not present in master. 

Should be relatively easy to fix?

[rhc54]

@jsquyres This commit (e4bdad0) is apparently what broke it - was done a long time ago to the v3.x branch. Do you remember why?

[jsquyres]

Heh -- I did that because you told me to do it. 😄

See #1281

[rhc54]

I think the problem is that the flag is still needed for the external modules, but I'll check it

[rhc54]

Hmmm....I confess I'm confused now because the pmix component configure.m4's in the HEAD of v3.1.x look exactly like the ones in master.

@abouteiller Can you provide more detail on exactly what you did to observe this problem?

[bwbarrett]

e4bdad0 is a correct change; for internal components, you should never need to add -lpmix (or similar) to extra_wrapper_libs, because the build system will add them for you late in the process (as long as they're component dependencies, which they are in that case).

I'm confused, what was the test case that broke: internal or external PMIx? If external, which version?

[jsquyres]

@abouteiller Ping.

[bwbarrett]

@jsquyres, @rhc54, @abouteiller comments? This is still marked as a blocker for 3.1. I'd like to understand the test case that caused the problem so we can resolve the blocker bit.

[jsquyres]

@rhc54 @abouteiller When I run the following on both master and the v3.1 branch (and on a v3.1 nightly tarball):

$ ./configure --enable-static --disable-shared ...

I do not get a PMIX build failure when I build MPI applications. I.e., everything works as I expect it to.

Can you describe the exact scenario that is failing?