execution of an external compiler program 'gcc -c -w -I/share/apps/nimrod/0.12.0/lib -o /my/path/nimcache/system.o /my/path/nimcache/system.c' failed with exit code: 256
/my/path/nimcache/system.c:23: error: redefinition of typedef ‘TNimType’/share/apps/nimrod/0.12.0/lib/nimbase.h:423: note: previous declaration of ‘TNimType’ was here
Seems like it might be an installation issue. There are multiple versions of nim installed on our computing cluster. I did not install them, but I want to figure out what going on before asking our cluster administrator to look into this.
You can try the following workaround. In lib/nimbase.h, replace the line
typedef struct TNimType TNimType;
with:
#if !defined(__GNUC__) || defined(__clang__) || ((__GNUC__ >= 4) && (__GNUC_MINOR__) >= 7)
typedef struct TNimType TNimType;
#endif
This will suppress the problematic typedef for affected versions of gcc (and introduces a small regression, see this old issue). While this can break code that uses Any, in practice, Any is not frequently used (and even less so in a context where the regression manifests).
Even better, use clang or a more recent version of gcc (gcc 4.5 has the bug, gcc 4.7 doesn't have it, and I'm not sure about 4.6). Using nim cpp also makes the problem go away, but the C++ code generator may not be an option in practice.
Some more information: the underlying problem lies with how C compilers handle duplicate typedefs.
Per C89/90 and C99, duplicate typedefs are not permitted; C11 expressly allows them.
However, this is not how they have been historically implemented. Some C compilers have allowed duplicate typedefs for a long time, and gcc has allowed them traditionally if at least one of the typedefs occurs in a system header. These days, gcc allows them regardless of the -std argument and clang only issues a warning if it sees a duplicate typedef with (e.g.) -std=c99.
The ideal long-term solution would be to fix the code generation to avoid the duplicate typedef rather than relying on the non-quite-standard behavior of clang and gcc (which may change again in the future, who knows), but this is not entirely trivial.