What rpmbuild does is sets the --libdir so things should work correctly
using that method. I can verify running configure without the --libdir
results in just $prefix/lib no matter the arch. I could see how that is
confusing. If someone submits a patch with a reasonable solution we
will evaluate it and get it in the next version. Don't worry about the
exotic systems like BG or Cray, we will.
As you are probably aware both rpmbuild and standalone configure both
use perl to the the PERLARCHLIB and only replace the prefix of that, you
can find what we do in the slurm.spec if you are interested. I don't
think changing that should happen. For what it is worth PERLARCHLIB is
lib on a 64bit ubuntu install. Redhat/CentOS appears to have lib64.
On 10/14/2014 06:52 PM, Jeff Squyres (jsquyres) wrote:
Moe / Danny / SchedMD in general --
Comments?
On Oct 14, 2014, at 5:41 PM, Michael Jennings <[email protected]> wrote:
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=...).
I agree with you. As for what the right answer is, hopefully Moe or
Danny will chime in at this point. Or someone from SchedMD. It's an
administrative choice as to which is the right way to go.
I think most folks would expect PERLARCHLIB to correlate with $libdir
(and $prefix/lib*) when using a custom prefix; I think it's quite
reasonable to take specific actions when --prefix is given (outside of
/usr and /usr/local) that aren't taken otherwise. But as I said
before, I don't have the BG/Cray experience to say what those systems'
expectations or caveats are. :-)
Michael
--
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
