Header compatibility with slurm 2.6

[GoogleCodeExporter]

When compiling pdsh against slurm 2.6 using gcc 4.1 and 4.4 (i.e.
the el5 and el6 compilers), I get symbol redefinition errors, below.
I don't get the error with gcc 4.6, but it seems useful to have the
compilation work on the stock compilers.

This patch adds some tests for the macros that slurm sets on the
symbols in question, so as to only use the first definition.

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I/usr/include -pthread -O3 -Wall
-fno-strict-aliasing -MT slurm.lo -MD -MP -MF .deps/slurm.Tpo -c slurm.c
-o slurm.o
In file included from slurm.c:50: /usr/include/slurm/slurm.h:663:
error: redefinition of typedef ‘hostlist_t’ ../../src/common/hostlist.h:59:
note: previous declaration of ‘hostlist_t’ was here
/usr/include/slurm/slurm.h:800: error: redefinition of typedef ‘List’
../../src/common/list.h:58: note: previous declaration of ‘List’ was here
/usr/include/slurm/slurm.h:805: error: redefinition of typedef 
‘ListIterator’
../../src/common/list.h:63: note: previous declaration of ‘ListIterator’ was
here /usr/include/slurm/slurm.h:810: error: redefinition of typedef 
‘ListDelF’
../../src/common/list.h:68: note: previous declaration of ‘ListDelF’ was 
here
/usr/include/slurm/slurm.h:817: error: redefinition of typedef ‘ListCmpF’
../../src/common/list.h:75: note: previous declaration of ‘ListCmpF’ was 
here
/usr/include/slurm/slurm.h:824: error: redefinition of typedef ‘ListFindF’
../../src/common/list.h:82: note: previous declaration of ‘ListFindF’ was 
here
/usr/include/slurm/slurm.h:830: error: redefinition of typedef ‘ListForF’
../../src/common/list.h:88: note: previous declaration of ‘ListForF’ was 
here

---
 src/common/hostlist.h | 3 +++
 src/common/list.h     | 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

Original issue reported on code.google.com by [email protected] on 10 Jan 2014 at 9:59

Attachments:

• pdsh-header-compatibility-with-slurm.patch

[GoogleCodeExporter]

Honestly I would have to call this a bug in SLURM. They shouldn't have exported 
these internal interfaces via a public header file, especially since they are 
breaking the very projects from which they initially _inherited_ the code in 
question. It just seems a bit dirty to change the upstream version of the code 
because SLURM decided to publicise these interfaces.

There are multiple LLNL initiated projects that use hostlist.[ch] and 
list.[ch], and because of this issue *they* all have to change (if any want to 
eventually also compile against slurm.h).

That being said the approach of wrapping typedefs in preprocessor macros seems 
like
it might be the only viable solution, especially if SLURM is unwilling to fix 
their header file. So, let me think some more about this one... but otherwise 
your fix seems fine.

Original comment by [email protected] on 18 Jan 2014 at 12:11

• Changed state: Accepted