On Oct 8, 2014, at 1:56 PM, Jeff Squyres (jsquyres) <[email protected]> wrote:
> > On Oct 7, 2014, at 4:18 PM, Michael Jennings <[email protected]> wrote: > >> Multiple possible solutions are available, depending on what users' >> expectations are and how Moe & Danny want things to be orchestrated by >> default. I would say further discussion should ensue if Timothy >> confirms that we have indeed pinpointed what's going on and that >> --libdir "fixes" the issue. > > Fair enough. Timothy: can you confirm that --libdir=.../lib64 does fix the > issue? Will do. > >> Is this a problem because OpenMPI uses the existence of the >> <prefix>/lib64 directory as a litmus test for something? I'm >> wondering why this particular scenario would adversely affect the >> OpenMPI code or build process. If you (or Timothy) wouldn't mind >> elaborating on the specific problem being encountered, that might be >> helpful! :-) > > If a non-default directory is provided as the location of SLURM (i.e., via > --with-slurm=DIR), then we check to make sure that directory exists (to > ensure that the user didn't typo the dirname). If it does, we look for > DIR/lib64, and if we find that, we add -LDIR/lib64 to LDFLAGS. But if we > don't fine that, then we look for DIR/lib, and if we find that we add > -LDIR/lib to LDFLAGS. Then we check for some symbols that should be in the > PMI library with whatever was put in LDFLAGS. > > Does that make sense? Yes and this is what the patch Ralph provided does. > > We're reluctant to put both lib and lib64 in LDFLAGS, because that can lead > to erroneous builds (e.g., a mix of 32 and 64 bit libraries, especially if > SLURM is installed in a tree with other packages). Totally agree here. Timothy=
