When using ThreadsPerCore > 1, it appears that DefMemPerCPU is being
scaled by slurmctld, but not by slurmd/slurmstepd.

For example, we set ThreadsPerCore=2 and DefMemPerCPU=100. Running a
single core job, we would expect two threads to be allocated and AllocMem
on the assigned node to increase by 200MB. scontrol reports that AllocMem
increased by 200MB, but the task/cgroup plugin only sees 100M of RAM.

It looks like the problem may lie in common/slurm_cred.c:format_core_allocs().
The function counts the job/step cores and multiplies the mem_limit's,
but it does not scale the CPU count like in slurmd/slurmd/req.c:_check_job_credential().
See bug 309

This is the correction of the slurm client which otherwise fails the
PMI2_Init() step. This hidden bug was introduced in the standalone
client made from BULL and David's modification made it occur : a wrong
size (by 1 too short) was passed to strncpy for keys, then David
replaced strncpy by MPICH's MPIU_Strncpy forcing a terminal '\0'.

Bug 359

messed up output.  Use the parsable options if you want this kind of
view.

The terminating task's PID is available in task->pid.

other plugins that need to layer plugins of the same type.

AM_CPPFLAGS could get overwritten and making it not happen when using
libtool

From http://www.gnu.org/software/automake/manual/html_node/Program-Variables.html

AM_CPPFLAGS is ignored in preference to a per-executable (or per-library)
_CPPFLAGS variable if it is defined.

INCLUDE variable rpmlint was complaining about them