With release 24.05.x, there are API Changes from SLURM that affect (in our environment) how the DRMAA package maintained by natefoo is built against SLURM libraries. Namely, there are places in the current code that reference the Java-based ListIterator interface used in Collection API. ListIterator causes build errors (in our environment), although it seems to be properly handled in the code from natefoo. There is certainly a more elegant way to go about the changes described below, but I needed something in-place quick and my coding skills don't always lend themselves to "quick."
From the SLURM v24.05.x release notes:
API CHANGES
===========
-- Removed ListIterator type from .
-- Removed slurm_xlate_job_id() from
Solution
- Replace
ListIterator with list_itr_t - the code already uses a conditional directive to switch between the two based on the SLURM version.
- Remove references to
ListIterator where possible in slurm_drmaa/slurm_missing.h and slurm_drmaa/job.c
- Fork
natefoo/slurm-drmaa and perform above tasks,
- Clone
fourzerosix/slurm-drmaa, being sure to --recurse-submodules and
- Edit the spec file to contain:
%setup -q -n slurm-drmaa
autoreconf -i
cd drmaa_utils
autoreconf -i
cd ..
- Rebuild the
.rpm from the source-code of the new package against a fully update/patched development-VM with slurm-24.05.4 installed
- Copy the
.rpm to an in-house yumrepos server and sign the package,
- Deploy the package alongside the new version of SLURM to our SLURM test cluster, and finally
- Test job submission
Error
- SLURM v24.05.4 on EL7
- CentOS Linux release 7.9.2009 (Core)
- Kernel: 3.10.0-1160.119.1.el7.x86_64
- When attempting to build against the above, received this error:
In file included from job.c:41:0:
../slurm_drmaa/slurm_missing.h:28:34: error: unknown type name 'ListIterator'
extern void * slurm_list_remove (ListIterator i);
^
job.c: In function 'slurmdrmaa_job_on_missing':
job.c:441:2: error: unknown type name 'ListIterator'
ListIterator itr = NULL;
- Updated
slurm_missing.h with >= in lieu of < in if statement and list_itr_t replacement, as expected, dropped an error during build:
( - ) #if SLURM_VERSION_NUMBER < SLURM_VERSION_NUM(24,5,0)
( - ) extern void * slurm_list_remove (ListIterator i);
( + ) #if SLURM_VERSION_NUMBER >= SLURM_VERSION_NUM(24,5,0)
( + ) extern void * slurm_list_remove (list_itr_t *i);
job.c: In function 'slurmdrmaa_job_on_missing':
job.c:441:2: error: unknown type name 'ListIterator'
ListIterator itr = NULL;
- Removed
ListIterator references from job.c else statement and was able to rpmbuild (make) successfully:
( - ) #else
( - ) ListIterator itr = NULL;
With release 24.05.x, there are API Changes from SLURM that affect (in our environment) how the DRMAA package maintained by
natefoois built against SLURM libraries. Namely, there are places in the current code that reference the Java-basedListIteratorinterface used in Collection API.ListIteratorcauses build errors (in our environment), although it seems to be properly handled in the code fromnatefoo. There is certainly a more elegant way to go about the changes described below, but I needed something in-place quick and my coding skills don't always lend themselves to "quick."From the SLURM v24.05.x release notes:
Solution
ListIteratorwithlist_itr_t- the code already uses a conditional directive to switch between the two based on the SLURM version.ListIteratorwhere possible inslurm_drmaa/slurm_missing.handslurm_drmaa/job.cnatefoo/slurm-drmaaand perform above tasks,fourzerosix/slurm-drmaa, being sure to--recurse-submodulesand.rpmfrom the source-code of the new package against a fully update/patched development-VM withslurm-24.05.4installed.rpmto an in-house yumrepos server and sign the package,Error
slurm_missing.hwith>=in lieu of<inifstatement andlist_itr_treplacement, as expected, dropped an error during build:ListIteratorreferences fromjob.celsestatement and was able torpmbuild(make) successfully: