[torqueusers] location of pam module

Lloyd Brown lloyd_brown at byu.edu
Thu Dec 16 10:46:14 MST 2010

On 12/15/10 9:39 AM, Lloyd Brown wrote:
> With as much effort as this is taking, I think it makes sense to go back
> to the support ticket tracker for this issue, since it's probably
> related in some way to the patch or associated deployment process.  When
> we have it figured out, I'll be sure to re-post on the list, for the
> benefit of the community at large, and hopefully will save someone else
> the work in the future.
> Thanks for all the help so far.
> Lloyd

Alright.  For those that are interested, I do have a solution for this
problem, at least for my environment.  I'm not sure I understand the
situation fully, but it's good enough for me.  Take from it what you want.

Basically, what I know at this point is this:
- When compiling on Linux, the Torque configure script tries several
times to detect whether or not it's a 64-bit version.  It does this by
compiling a simple file, then running "file" on the result, and
examining the output.  This populates a variable named "libsuff" with
either nothing ("") if 32-bit, or "64" if 64-bit.  Why it tries multiple
times, I don't know, and subsequent checks overwrite previous checks'
results into "libsuff"; presumably the autoconf tools or something are
automatically generating the configure script, and so some code is
getting replicated.  Later, the "pammomdir" is defined as
"/lib$libsuff/security", and this is pushed into the makefile, and the
torque.spec file.
- At some point, I or one of my colleagues installed both Intel and
Portland Group compilers on the host I was compiling on, in addition to
the GNU compilers that were already there
- I took it for granted that the autodetection code (wherever that is),
would choose GNU compilers, and failed to specify them via the
CC/CXX/F77 variables during the configure stage
- The autodetection code grabbed the pgf77 compiler, and shoved it into
the F77 variable.  At the detection stage where it used the F77
variable, the configure script failed to compile anything; I'm not sure
why.  Therefore, the "libsuff" reverted back to the default of "",
instead of the "64" it should have been.

So, in the end, I simply added "CC=gcc CXX=g++ F77=gfortran" to the
beginning of my configure line, and everything goes back to the way I
expect, namely that it uses GNU compilers again, and that it pushes the
PAM module into "/lib64/security" again.

As I said, I probably should have noticed when it was using PGI
compilers.  Some day I might even dig and figure out why it was doing
that.  Right now, though, I'm not sure I care enough.

Thanks everyone for your help in tracking this down, both those on, and


Lloyd Brown
Systems Administrator
Fulton Supercomputing Lab
Brigham Young University

More information about the torqueusers mailing list