On Wednesday, 08 October 2014, at 12:55:59 (-0700),
Jeff Squyres (jsquyres) wrote:

> 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).

Makes total sense, and I agree with your methodology.  It would be
possible to check for the presence of actual libraries in each
directory rather than just the existence of the directories
themselves, but I can understand that you might be hesitant to do
that.

Unfortunately it's a complex issue:  On RHEL6 x64, all arch-specific
lib paths are lib64-based for multilib reasons, and since SLURM has a
.xs component, it needs to go into one of those.  That being said, if
a custom prefix is being used, it should be perfectly reasonable to
use /lib instead of /lib64 *iff* the site doesn't need multilib for
that prefix/module.  It's arguable whether or not SLURM can safely
assume that.

The most correct fix, IMHO, is for both SLURM's configure script and
its Perl Makefile(.PL) to be multilib-aware, or both not.  Either
force the Perl stuff to go in <prefix>/lib[1] if a custom prefix is
specified (i.e., not /usr or /usr/local), or force the configure
script to be multilib-aware by default on systems which are otherwise
multilib-aware (perhaps by looking for /lib64 or /usr/lib64).  But I
don't have the breadth of BlueGene/Cray/non-RHEL expertise required to
judge what the implications of this might be for other systems.

Michael

[1] This might be as simple as passing PERLARCHLIB=${prefix}/lib/perl5

-- 
Michael Jennings <[email protected]>
Senior HPC Systems Engineer
High-Performance Computing Services
Lawrence Berkeley National Laboratory
Bldg 50B-3209E        W: 510-495-2687
MS 050B-3209          F: 510-486-8615

Reply via email to