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? > 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? 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). -- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
