On Oct 8, 2014, at 4:39 PM, Michael Jennings <[email protected]> wrote:
>> 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.
Yes, it can (and has) led to broken scenarios for users (confusion about mixing
32 and 64 bit libraries in the same build).
> 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.
Agreed; it wouldn't be good to assume this. But it should be easy enough to
check and see if libtool is going to install into one place and perl is going
to install into another. And if that's the case, perhaps configure should
error out.
> The most correct fix, IMHO, is for both SLURM's configure script and
> its Perl Makefile(.PL) to be multilib-aware, or both not.
Yes. Or perhaps configure could just error out if it detects a mismatch (and
therefore let a human figure out, perhaps by supplying --libdir to override lib
tool's default install location, etc., or passing PERLARCHLIB=...).
> [1] This might be as simple as passing PERLARCHLIB=${prefix}/lib/perl5
I stole this suggestion for the above paragraph. :-)
--
Jeff Squyres
[email protected]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
